Hi Jerome, >> So that means udev rules. [...] If you are unlucky you need a DT overlay >> or hardcode it. > > So I've followed your suggestion and I've created a udev rule (on a Debian > system). Here is what it looks like for the moment, choosing first the > simpler hardcoding option: > > jdb@thinkpad8:~$ cat /etc/udev/rules.d/99-bluetooth-attach-broadcom.rules > SUBSYSTEM=="tty", KERNEL=="ttyS1", KERNELS=="80860F0A:00", > RUN+="/usr/bin/btattach --bredr /dev/ttyS1 -P bcm" > > Rebooting the tablet, good news, the rule seems to properly execute as I can > find btattach in the list of running processes: > > jdb@thinkpad8:~$ ps auxw | grep btattach > root 1155 0.0 0.0 6372 728 ? S 22:04 0:00 > /usr/bin/btattach --bredr /dev/ttyS1 -P bcm > > and I can see the firmware loading happening quite early in the boot process > > jdb@thinkpad8:~$ dmesg | grep "bluetooth.* firmware" > [ 5.528293] bluetooth hci0: firmware: direct-loading firmware > brcm/BCM.hcd > > However to my surprise Bluetooth is not enabled properly or at all, the > Bluetooth panel in the Gnome settings remains grayed out and bluetoothctl > doesn't detect a Controller. At some later points, I even see the btattach > process disappear by itself. > > That's just an uneducated assumption but it seems that somehow I am hitting > a timing condition issue and maybe it ends up trying to attach too early > (compared to what precisely? I have no idea). I'm saying this because if I > launch the btattach command manually at any later timee, it works fine. > > Do you have any guess of what could be the issue I'm hitting here? Any > logs/commands in particular that would be useful? > > >> Until then, you need an userspace part that triggers btattach with the >> right hardware id on the right /dev/ttySx device node as soon as it >> becomes available. > > Maybe my mistake is that I've interpreted your sentence: "as soon as *it* > becomes available" to assume that "it" was referring to the /dev/ttyS1 > device node. I'll try to see if I can create another udev rule that would > trigger based on the actual BT chipset becoming available, and not based on > /dev/ttyS1 , but I'm still looking for how to do it with dev. maybe the RFKILL switch part gets discovered later than the TTY. I don't have a platform to verify, but just at few printk into the probe routine and see if its finds the according GPIOs for power control. 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
