Hi Johan,
>>> There are several possible reason codes that can be sent in the command
>>> reject L2CAP packet. Before this patch the code has used a hard-coded
>>> single response code ("command not understood"). This patch adds a
>>> helper function to map the return value of an L2CAP handler function to
>>> the correct command reject reason.
>>>
>>> Signed-off-by: Johan Hedberg <johan.hedberg@xxxxxxxxx>
>>> ---
>>> net/bluetooth/l2cap_core.c | 22 ++++++++++++++++++----
>>> 1 file changed, 18 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
>>> index b3bb7bc..83acb28 100644
>>> --- a/net/bluetooth/l2cap_core.c
>>> +++ b/net/bluetooth/l2cap_core.c
>>> @@ -5294,6 +5294,20 @@ static inline int l2cap_le_sig_cmd(struct l2cap_conn *conn,
>>> }
>>> }
>>>
>>> +static u16 l2cap_err_to_reason(int err)
>>
>> what we could to is return __le16 here. And then keep using
>> __constant_cpu_to_le16.
>
> I was mainly trying to follow the principle of using host endianness
> until the very moment when we actually encode into the protocol struct.
> However, I agree that we could be more pragmatic here since the only
> users of this function are places where we're directly encoding into the
> response PDU.
the thing is that within the kernel you can nicely mark the endian of the return value with __le16. So tools like sparse will warn you if you mess it up.
>>> +{
>>> + switch (err) {
>>> + case -EFAULT:
>>> + return L2CAP_REJ_INVALID_CID;
>>> + case -EMSGSIZE:
>>> + return L2CAP_REJ_MTU_EXCEEDED;
>>> + case -EINVAL:
>>> + case -EPROTO:
>>> + default:
>>> + return L2CAP_REJ_NOT_UNDERSTOOD;
>>> + }
>>> +}
>>
>> Is there really a point in listing EINVAL and EPROTO here.
>
> I thought it would make it clear which error codes are recommended for
> parsing errors but I can remove them and just rely on default.
I am fine keeping them. Just asking.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
