| 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
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(+)