Hi Pavel, >>> Hacks surrounding bluetooth address were removed; this results in >>> working driver with address that is probably not unique. >> >> Just set HCI_QUIRK_INVALID_BDADDR and let someone deal with that in >> userspace. You can use the btmgmt public-addr command for testing. >> > > Ok, it took me a while to figure out that --enable-experimental is > needed. > > Then help was playing tricks with me: > > For more information on the usage of each command use: > btmgmt <command> --help > root@n900:/my/bluez-5.26/tools# ./btmgmt public-addr --help > Set Public Address for hci0 failed with status 0x0b (Rejected) > root@n900:/my/bluez-5.26/tools# ./btmgmt public-addr > Usage: btmgmt public-addr <address>
that is indeed confusing. Something went wrong with that tool. Just keep in mind that tool is just for internal testing by the developers. Someone would still need to write a proper integration with listening for the appropriate events and dig out the actual address from the memory location. > root@n900:/my/bluez-5.26/tools# ./btmgmt public-addr 01:02:03:04:05:06 > Set Public Address for hci0 failed with status 0x0b (Rejected) > > Hmm. Since setting public address only works when interface is down, > and we lose all the settings during up, this does not work at all, > right? It does keep it. The address is stored in hdev->public_addr which is actually different from hdev->bdaddr which is the current address in use. However I am not sure that hdev->set_bdaddr is executed again. Same as hdev->setup is not executed twice. The controller loosing all states is something we have not yet encountered. At least not while the hci_dev stays around. I wonder if the drastic power off might be better hooked into a platform RFKILL switch. And with that you would just unregister hci_dev and re-register it when the RFKILL switch is unblocked. The other option is to introduce a quirk that allows running hdev->setup and hdev->set_bdaddr all the time when you bring up your device. Another alternate idea for getting something upstream for testing is to ignore the whole firmware loading in the kernel and bring up the controller with HCI_QUIRK_EXTERNAL_CONFIG. Doing that would allow you to do bette testing and evolve the driver in small tests. So what this quirk does is that the hci_dev comes up unconfigured. So mgmt interface will only show it as unconfigured controller. However you can open it with HCI User Channel and run all HCI commands manually. That is what src/shared/hci.[ch] is good at. Once you are done, you just flip the switch via btmgmt ext-config and then the kernel goes and treats it as fully configured. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
