Hi Fred, >>>> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs. >> So I am convinced when we run on hardware that has no GPIO resources exposed (as it is with RPi right now), we should limit the operational speed to the initialization speed. And then my problem actually goes away. It also forces people to get the GPIOs exposed or they have to stick with a slower HCI transport. > > We may also reset to initialization speed on module unload. > This will allow multiple tests on the hardware, even if it does not have GPIOs exposed. you would have to do that on hci_unregister_dev and that is also tricky. If the device is down, we need to spin the transport back up and actually support HCI transaction like within hdev->setup(). It also means that we would have to take care of a lot of struct device lifetime rules etc since this might actually take some time. And if it still fails, the device is still borked. So I had thought about this briefly and looked into adding infrastructure into Bluetooth core for a hdev->cleanup() function, but just adding it for a hardware that actually has a GPIO, but doesn’t expose it right now seems really like a lot of code for nothing. This means limiting it to 115200 baud initially until someone comes along and gets the GPIO integrated seems more encouraging than hacking around it. And this would be hacking around it. 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
