A more refined approach consists in creating a
udev rule, triggered only when the right hardware is present, to launch the needed
btattach command from a
systemd service. This is merging the concepts of the 2 earlier answers.
For the specific chipset mentioned in the question, the
udev rule looks simply like this:
$ cat /etc/udev/rules.d/99-bluetooth-btattach.rules
KERNEL=="BCM2E55:00", RUN+="/bin/systemctl --no-block start btattach-broadcom-ttyS1.service"
with BCM2E55:00 being the hardware ACPI identifier of the corresponding Bluetooth chipset.
The systemd service, compatible only with chipsets appearing as a child of the ttyS1 device node (visible via sysfs in
/sys/devices/platform/80860F0A:00/tty/ttyS1/device/BCM2E55:00$), can remain very simple like this:
$ cat /etc/systemd/system/btattach-broadcom-ttyS1.service
Description=Start btattach, needed to enable Bluetooth for some UART-based Bluetooth Broadcom chipsets
# A delay is needed, 1s seems enough
ExecStart=/usr/bin/btattach --bredr /dev/ttyS1 -P bcm
systemd service will work as-is for other Broadcom chipsets (hence the
-P bcm parameter) appearing as a child of ttys1 (hence the
/dev/ttyS1); only the
udev rule needs to be completed to include the ACPI identifiers of other chipset variants.
For Broadcom chipsets attaching to a different ttyS* node, another similar
systemd service can be created to cover this case (or maybe the right parameters could be shared from the udev rule to the systemd service).
Rebooting the tablet shows that the
btattach command is properly executed at boot:
$ ps auxw | grep btattach
root 2059 0.0 0.0 6372 720 ? Ss 23:17 0:00 /usr/bin/btattach --bredr /dev/ttyS1 -P bcm
and Bluetooth is actually enabled and working! The Gnome Bluetooth settings does list connected and scanned devices and running
$ bluetoothctl from a command line properly shows the controller.
Surprisingly, when removing the initial 1s sleep command used to simply delay the real command, Bluetooth isn't working at all and not properly enabled despite
btattach still appearing to be running correctly in the list of background processes.
Not sure to understand what's happening exactly quite yet: there is a timing issue at stake and certainly a required dependency to wait for, before being supposed to launch btattach...