Hi Anderson, >>>> + /* AMP controllers do not need stage 2/3 init */ >>>> + if (hdev->dev_type != HCI_BREDR) >>>> + return 0; >>> >>> What about checking for "dev_type == HCI_AMP" instead? I had to check >>> net/bluetooth/hci.h because for a moment I thought Dual mode and >>> single mode LE devices were being left out as well. I then realized >>> you can only have BREDR vs. AMP controller types. >> >> 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. Or start complaining to the Bluetooth SIG, that we can not tell AMP controllers apart from BR/EDR controllers on the HCI level. Unless we start checking for some magic supported HCI commands/events, but there is clearly no standard. And the init procedure of the two controller types to differ. 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
