Hi Marcel, On Mon, Mar 04, 2013, Marcel Holtmann wrote: > >> 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. Johan -- 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
