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

[Colin Ian King]

On 16/01/2019 15:55, Paolo Pisati wrote:
> 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(+)
> 

Is this upstream-able?

Anyhow, useful workaround.

Acked-by: Colin Ian King <colin.king at canonical.com>