search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
10.88k stars 4.89k forks source link

hci0 interface present on non-Bluetooth devices #5756

Open agners opened 7 months ago

agners commented 7 months ago

Describe the bug

With the kernel Bluetooth initialization it seems that the hci0 device is always present, even on devices without WiFi/Bluetooth module on it (in my tests case a CM4 without WiFi/Bluetooth).

This does not seem to be problematic for BlueZ, but other user space software might get confused.

Not sure if this could be resolved in firmware (e.g. disable Bluetooth if not present). I've had the idea to use an overlay and use model filters in config.txt, but there seems to be no WiFi/Bluetooth specific model filter. Also revision codes don't seem to have a suitable bit. Maybe there is another way to get this done?

With observed this issue on Home Assistant OS after updating to the latest kernel (see https://github.com/home-assistant/operating-system/issues/2944).

Steps to reproduce the behaviour

Install Raspberry Pi OS on a CM4 without WiFi/Bluetooth. Run hciconfig:

pi@rpioscm4:~ $ hciconfig 
hci0:   Type: Primary  Bus: UART
        BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
        DOWN 
        RX bytes:0 acl:0 sco:0 events:0 errors:0
        TX bytes:14 acl:0 sco:0 commands:2 errors:0

Device (s)

Raspberry Pi CM4

System

pi@rpioscm4:~ $ cat /etc/rpi-issue Raspberry Pi reference 2023-10-10 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 962bf483c8f326405794827cce8c0313fd5880a8, stage4

Logs

No response

Additional context

No response

pelwell commented 7 months ago

That is interesting, and not what I expected. I'll take a look if there's some kernel or Device Tree setting which is overriding the default kernel behaviour and forcing hci0 to be created, but, if not, we may have to document it somewhere and live with it.

agners commented 7 months ago

The probing also leads to kernel errors, e.g.

[   17.630934] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
[   17.637712] Bluetooth: hci0: Failed to set baudrate
[   19.646891] Bluetooth: hci0: command 0x0c03 tx timeout
[   27.870915] Bluetooth: hci0: BCM: Reset failed (-110)

I guess from the kernel's perspective, the device is supposed to be there, as state by the device tree. Ideally the something (probably firmware) should disable the bluetooth nodes in this cases.

pelwell commented 7 months ago

On CM4 the information about WiFi population is available in boardrev_ext, but I'm nervous that using the value there to disable the Bluetooth node in the DTB could have unintended consequences if somebody has done something funny such as (for example) enabling the UART on the GPIO header and fitting an external modem to add Bluetooth to a CM4 that doesn't have it.

agners commented 7 months ago

Hm, I see, that would be under the same uart0 node :thinking:

I understand that altering the device tree from firmware is a bit iffy. Maybe the node name could be changed to internalbt, to make it clear that this is not meant to be used externally? Then a user which adds a module externally just would need to adjust that name to something else to prevent the firmware from touching it? :thinking:

In the end, the device tree should describe the hardware accurately, and currently this isn't really the case for the CM4 without Bluetooth/WiFi.

A way to pass a different device tree(/or overlay) by means of config.txt would be helpful for custom operating systems.