Hi Johan, >>>> This logic is a direct copy-paste from the beginning of the existing >>>> hci_setup() function in net/bluetooth/hci_event.c. I could change it to >>>> test specifically for AMP, but then what happens if we add more dev_type >>>> values that also shouldn't have more than the stage 1 init? In that case >>>> a stricter != HCI_BREDR test is safer than a looser == HCI_AMP test. >>> >>> My concern is that the "HCI_BREDR" name is a bit misleading, specially >>> if it matches a single mode LE device (is that the case?) >>> >>> If changing the macro name is not an option, can it be clarified on >>> the comment? >> >> the HCI_BREDR and HCI_AMP define the difference between a BR/EDR >> and/or LE controller and the AMP controller. It does not define the >> difference between BR/EDR and LE. >> >> While the name is not super perfect, it makes sense from a historic >> point of view how Bluetooth as a technology evolved. If you figure out >> a better naming, let me know. > > The only idea I have is HCI_BREDRLE (since the core spec uses > "BR/EDR/LE" for dual mode references). I'll anyway try to clarify the > code comment that was partly responsible here. which is an even worse letter soup ;) And might be even more confusing when you really have single BR/EDR only controller which is still pretty much common these days. So the fact that a LE only controller would be labeled as HCI_BREDR is confusing, but then again, the cases where BlueZ is normally used (besides testing) we will not see an LE only controller anyway. So optimizing for that case is rather pointless since no matter what we do, we have a trade off here. A2MP uses the term "Primary BR/EDR controller". So we could use HCI_PRIMARY, but even that is confusing since BlueZ has been supporting multiple controllers since the beginning. So for me it is HCI_BREDR and unless some one comes up with a better name, it should stay that way. Regards Marcel -- 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
