** Description changed: + Impact: + + Upon boot, no hci device is available to userspace, thus bluetooth + communication is not possible. + + Defect analysis: + + The root of the problem lies in these two patches: + + $ git log --online drivers/bluetooth/btqcomsmd.c + + ... + 766154b Bluetooth: btqcomsmd: retrieve BD address from DT property + 6e51811 Bluetooth: btqcomsmd: Add support for BD address setup + ... + + Qualcomm engineer found that btqcomsmd had no BD address burned in (nor + via ROM, neither internally) and it was always coming up with the same + address, probably derived from manufacturer ID and / or chip ID. + + To fix this, they pushed the burden of generating a unique per-board BD + address to the Qualcomm bootloader and make it pass down via DTB to the + live kernel - and if no address was present in the DTB, the hci was left + unconfigured. + + Fix: + + So *technically* speaking, the kernel is correct in this case, it's our + dragonboard image (e.g. Ubuntu Core) that doesn't extract the generated + BD address from the Qualcomm bootloader and pass it down to the kernel. + + On the other hand, having Bluetooth working out of the box (even with a + dummy address), is a nice feature to have, so i slightly modified + Qualcomm's code introduced in the two above patches, and made the lack + of DB address in DTB non fatal: + + if DTB_has_BD_address() + read_BD_addr_and_apply_it() + else + default_back_to_dummy_addr() + end if + + And surrounded the modification in #ifdef...#endif brackets to keep it + local. + + How to test: + + By default, on a patched kernel, the hci device will have a default + address: + + ubuntu@dragon410c:~$ hcitool dev + Devices: + hci0 00:00:00:00:5A:AD + + the address " 00:00:00:00:5A:AD" might vary per board, but will be + consistent after every reboot. + + The other option is to specify a custom address via dtb, e.g. using uboot to manipulate the dtb - we assume the dtb ws loaded in memory at ${fdt_addr}: + + dragonboard410c => fdt addr ${fdt_addr} + + dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/ + bt { + compatible = "qcom,wcnss-bt"; + }; + + dragonboard410c => fdt resize + + dragonboard410c => fdt set /soc/wcnss/smd-edge/wcnss/bt/ local-bd- + address [ 55 44 33 22 11 00 ] + + dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/ + bt { + local-bd-address = [55 44 33 22 11 00]; + compatible = "qcom,wcnss-bt"; + }; + + then proceed with the rest of the boot process and check hci: + + $ hcitool dev + Devices: + hci0 00:11:22:33:44:55 + + In both cases, blueooth work afterward, and can be used to communicate + with other devices: + + ubuntu@dragon410c:~$ hcitool scan + Scanning ... + C0:BD:54:12:4E:D1 My dummy device + + + Regression potential: + + None, the fix is surronded with #ifdef...#endif thus it doesn't exist + outside of it. + + -- + + Using the core18 image from http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ Kernel snap: 4.15.0-39.42 (72) rfkill shows there is an hci0 device: $ rfkill list 0: hci0: Bluetooth - Soft blocked: no - Hard blocked: no + Soft blocked: no + Hard blocked: no 1: phy0: Wireless LAN - Soft blocked: no - Hard blocked: no + Soft blocked: no + Hard blocked: no But bluetoothctl does not detect any controller: $ sudo bluetoothctl 08:58 Agent registered 08:58 [bluetooth]# list [...no output...] If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works: $ sudo bluetoothctl [NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default] Agent registered [bluetooth]# list Controller 00:00:00:00:5A:AD BlueZ 5.47 [default] [bluetooth]# show Controller 00:00:00:00:5A:AD - Name: BlueZ 5.47 - Alias: BlueZ 5.47 - Class: 0x00000000 - Powered: no - Discoverable: no - Pairable: yes - UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) - UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) - UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb) - UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) - UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb) - UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) - UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) - UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb) - UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001) - UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb) - UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb) - UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb) - Modalias: usb:v1D6Bp0246d052F - Discovering: no + Name: BlueZ 5.47 + Alias: BlueZ 5.47 + Class: 0x00000000 + Powered: no + Discoverable: no + Pairable: yes + UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) + UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) + UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb) + UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) + UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb) + UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) + UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) + UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb) + UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001) + UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb) + UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb) + UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb) + Modalias: usb:v1D6Bp0246d052F + Discovering: no
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1810797 Title: bluetooth controller not detected with 4.15 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-snapdragon/+bug/1810797/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs