Hi Marcel,
On Sat, Sep 14, 2013, Marcel Holtmann wrote:
> > 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.
> > +{
> > + 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.
Johan
--
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
