** 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
+ of DB address in DTB non fatal.
  
  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
+         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}:
-  
+ 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";
+         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/                    
               
+ dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
  bt {
-         local-bd-address = [55 44 33 22 11 00];
-         compatible = "qcom,wcnss-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
+         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
- 
+         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
  1: phy0: Wireless LAN
   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

** 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.
  
  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 address " 00:00:00:00:5A:AD" might vary, 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
+ The other option is to specify a custom BD address, e.g. using uboot to
+ manipulate the dtb - we assume the dtb was 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
  1: phy0: Wireless LAN
   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

** 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.
+ of BD address in DTB non fatal.
  
  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, but will be consistent
  after every reboot.
  
  The other option is to specify a custom BD address, e.g. using uboot to
  manipulate the dtb - we assume the dtb was 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
  1: phy0: Wireless LAN
   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

** 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 BD address in DTB non fatal.
+ of BD address in DTB non fatal:
+ 
+ if BD_is_present_in_DTB()
+     read_BD_and_apply_setup()
+ else
+     let_hci_core_generate_BD()
+ 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, but will be consistent
  after every reboot.
  
  The other option is to specify a custom BD address, e.g. using uboot to
  manipulate the dtb - we assume the dtb was 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
  1: phy0: Wireless LAN
   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

** Patch added: "0001-UBUNTU-SAUCE-btqcomsmd-introduce-BT_QCOMSMD_HACK.patch"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810797/+attachment/5229695/+files/0001-UBUNTU-SAUCE-btqcomsmd-introduce-BT_QCOMSMD_HACK.patch

-- 
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/+bug/1810797/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to