[PATCH 0/2] [B/master][SRU] arm64: snapdragon: Fix bluetooth controller in Dragonboard410c

[Paolo Pisati]

BugLink: https://bugs.launchpad.net/bugs/1810797

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:

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 at 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 at 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.

Paolo Pisati (2):
  UBUNTU: SAUCE: btqcomsmd: introduce BT_QCOMSMD_HACK
  UBUNTU: [Config] arm64: snapdragon: BT_QCOMSMD_HACK=y

 debian.master/config/amd64/config.common.amd64       | 1 +
 debian.master/config/arm64/config.flavour.generic    | 1 +
 debian.master/config/arm64/config.flavour.snapdragon | 1 +
 debian.master/config/armhf/config.common.armhf       | 1 +
 debian.master/config/i386/config.common.i386         | 1 +
 debian.master/config/ppc64el/config.common.ppc64el   | 1 +
 drivers/bluetooth/Kconfig                            | 7 +++++++
 drivers/bluetooth/btqcomsmd.c                        | 5 +++++
 8 files changed, 18 insertions(+)

-- 
2.17.1