APPLIED[D/Unstable]: [PATCH 0/2] [C-D/master][SRU] arm64: snapdragon: Fix bluetooth controller

[Seth Forshee]

On Tue, Jan 22, 2019 at 05:20:28PM +0100, Paolo Pisati wrote:
> Exactly the same patches that landed in B/master, this time for Cosmic and
> Disco / master - mechanical modification to make the config patches apply,
> while the SAUCE patch is identical - i already applied cking and smb acks.
> 
> --
> 
> 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.

Applied to disco/master-next and unstable/master, thanks!