Hi Stefan, >>>>>>>>> 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. >>>>> >>>>> I prefer this solution instead of coding workarounds within the devicetree. >>>> >>>> DT is actually for encoding workarounds for the hardware. If the GPIOs are not exposed, we are actually limited. However I am going to do that in the hci_bcm.c driver itself since it is a more wider problem. If the GPIO resources are not available, the device will actually not function. This is actually a valid assumption for all hardwired Bluetooth chips. They all have some GPIO or power control option. The only reason to not have GPIOs would be external development boards. So the RPi with the not exposed GPIOs is kinda broken hardware right now. That we got this far supporting Bluetooth on it has to be considered pure luck :) >>> >>> only to make sure that we talking about the same, please take a look at my attempt for the RPi Zero W [1]. >>> >>> Using the BT_ON signal as shutdown-gpio is not enough? I'm sorry i didn't test the reload case yet. >>> >>> So after the implementation of the RPI firmware expander driver, we still need this baudrate limitiation? >>> >>> Btw Baruch said that he will send a new version of his patch series soon. >>> >>> [1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a69f2e32d35827635b95cf966 >> >> before you include "shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;” we might need to figure out on how the BT_ON GPIO is working and what it is suppose to be doing. But otherwise the patch fro the Zero W looks right to me. >> >> Also keep in mind that the current 4.16-rc2 kernel will require the shutdown-gpios and device-wakeup-gpios both to be available. We have not yet tested this when only shutdown-gpios is available. You might need to modify bcm_get_resources and bcm_gpio_set_power to test this out. > > i think this contradicts to the binding documentation, which defines both as optional. the 4.15 kernel might be fine actually while the support for Apple hardware with Broadcom UART devices might have accidentally required this now. Maybe you just want to hack your kernel and see how it goes when just having the shutdown-gpios available. I am super curious if the firmware resets and falls back to the ROM state or if something is actually kept. 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
