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@xxxxxxxxxx> >>> Signed-off-by: Manish Mandlik <mmandlik@xxxxxxxxxx> >>> --- >>> >>> 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
