[lkml]   [2020]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Bluetooth: Do not cancel advertising when starting a scan
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 <>
>>> Signed-off-by: Manish Mandlik <>
>>> ---
>>> 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.



 \ /
  Last update: 2020-03-18 12:56    [W:0.041 / U:3.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site