[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <106789BA-48C0-4428-BE3E-D0737F7A0641@holtmann.org>
Date: Wed, 19 Nov 2014 07:01:42 +0900
From: Marcel Holtmann <marcel@...tmann.org>
To: Steven Walter <stevenrwalter@...il.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
BlueZ development <linux-bluetooth@...r.kernel.org>,
"Gustavo F. Padovan" <gustavo@...ovan.org>,
Johan Hedberg <johan.hedberg@...il.com>
Subject: Re: [PATCH] l2cap_core: automatically flushable packets aren't supported by LE-only devices
Hi Steven,
> The bluetooth spec states that automatically flushable packets may not
> be sent to a LE-only controller. The code already supports
> non-automatically-flushable packets, but uses a bit in the controller
> feature field to determine whether to use them. That bit is always zero
> for LE-only devices, so we need to check for the LE-only case explicitly.
> ---
> net/bluetooth/l2cap_core.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 4af3821..29d9b9c 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -764,7 +764,7 @@ static void l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16 len,
> if (!skb)
> return;
>
> - if (lmp_no_flush_capable(conn->hcon->hdev))
> + if (lmp_no_flush_capable(conn->hcon->hdev) || !lmp_bredr_capable(conn->hcon->hdev))
> flags = ACL_START_NO_FLUSH;
> else
> flags = ACL_START;
> @@ -798,8 +798,9 @@ static void l2cap_do_send(struct l2cap_chan *chan, struct sk_buff *skb)
> return;
> }
>
> - if (!test_bit(FLAG_FLUSHABLE, &chan->flags) &&
> - lmp_no_flush_capable(hcon->hdev))
> + if (!lmp_bredr_capable(hcon->hdev) ||
> + (!test_bit(FLAG_FLUSHABLE, &chan->flags) &&
> + lmp_no_flush_capable(hcon->hdev)))
> flags = ACL_START_NO_FLUSH;
> else
> flags = ACL_START;
I do not think doing it this way is correct. I am actually surprised that it using fine right now, but I assume that is because all dual-mode controllers also support non-flushable packets.
We should check the link type of the connection and if it is LE then we should always use non-flushable packets. The feature bits have really nothing to do with this. They only apply to the BR/EDR side of things. LE has its own supported feature bits.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists