Re: [PATCH] Bluetooth: Do not cancel advertising when starting a scan

[Marcel Holtmann <marcel@holtmann.org>]

Hi Emil,

>>> BlueZ cancels adv when starting a scan, but does not cancel a scan when
>>> starting to adv. Neither is required, so this brings both to a
>>> consistent state (of not affecting each other). Some very rare (I've
>>> never seen one) BT 4.0 chips will fail to do both at once. Even this is
>>> ok since the command that will fail will be the second one, and thus the
>>> common sense logic of first-come-first-served is preserved for BLE
>>> requests.
>>> 
>>> Signed-off-by: Dmitry Grinberg <dmitrygr@google.com>
>>> Signed-off-by: Manish Mandlik <mmandlik@google.com>
>>> ---
>>> 
>>> net/bluetooth/hci_request.c | 17 -----------------
>>> 1 file changed, 17 deletions(-)
>> 
>> patch has been applied to bluetooth-next tree.
>> 
>> If you know the controller that doesn’t support this, can we blacklist that one and just disable advertising (peripheral mode) for that controller.
> 
> Can't the "LE Supported States" be inspected instead to figure out
> what simultaneous capabilities are supported? It seems a bit rough to
> always assume the worst.

if there are not false-positives, then yes, by all means. However my statement still applies. If a controller can do scanning and advertising at the same time, we should just not indicate support for peripheral mode.

Regards

Marcel