Message ID | 1547654139-18487-1-git-send-email-paolo.pisati@canonical.com |
---|---|
Headers | show |
Series | arm64: snapdragon: Fix bluetooth controller in Dragonboard410c | expand |
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@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. > > 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@canonical.com>
On Wed, Jan 16, 2019 at 5:08 PM Colin Ian King <colin.king@canonical.com> wrote:
> Is this upstream-able?
Might be, i'll give it a shot.
On 16.01.19 16: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@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. > > 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(+) > Acked-by: Stefan Bader <stefan.bader@canonical.com>
On 16.01.19 16: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@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. > > 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(+) > Oh ... what about Cosmic/Disco/Unstable?
Uhm, good point, i didn't check there (since Ubuntu Core is using Bionic kernel), but i'll do. On Mon, Jan 21, 2019 at 3:32 PM Stefan Bader <stefan.bader@canonical.com> wrote: > > On 16.01.19 16: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@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. > > > > 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(+) > > > > Oh ... what about Cosmic/Disco/Unstable? >
On 2019-01-16 16:55:37 , 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@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. > > 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 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team