Re: btattach: auto triggering at boot time by Linux distributions

Hi Jerome,

quoted

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?

quoted

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