Bluetooth: qca: fix device-address endianness
Subsystems (8)
v2 cover Bluetooth: qca: fix device-address endianness
The Qualcomm Bluetooth driver is configuring the device address in reverse order for none-ROME devices, which breaks user space tools like btmgmt and the 'local-bd-address' devicetree property.
As these Qualcomm controllers lack persistent storage for the device address, boot firmware can use the 'local-bd-address' devicetree property to provide a valid address. The property should specify the address in little endian order, but instead some boot firmware has been reversing the address to match the buggy Qualcomm driver.
This specifically affects some Chromebook devices for which we now need to maintain compatibility by deprecating the affected compatible string, marking the corresponding devicetree properties as broken, and reversing the addresses after parsing them. Fortunately, only 'qcom,wcn3991-bt' is impacted and needs to be deprecated this way according to the Chromium team [1].
Note that this series depends on the following revert:
https://lore.kernel.org/lkml/[email protected]/
Johan
[1] https://lore.kernel.org/lkml/[email protected]/
Changes in v2
- add quirk to handle deprecated devicetree compatibles that expect broken address properties
- deprecate 'qcom,wcn3991-bt' and mark it as broken
Johan Hovold (4):
dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
Bluetooth: add quirk for broken address properties
Bluetooth: qca: fix device-address endianness
Bluetooth: qca: fix wcn3991 'local-bd-address' endianness
.../net/bluetooth/qualcomm-bluetooth.yaml | 29 +++++++++++-------- drivers/bluetooth/btqca.c | 8 +++-- drivers/bluetooth/hci_qca.c | 11 +++++++ include/net/bluetooth/hci.h | 10 +++++++ net/bluetooth/hci_sync.c | 5 +++- 5 files changed, 48 insertions(+), 15 deletions(-)
Signature · 1 line
2.43.2
PATCH v2 1/4 dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
Several Qualcomm Bluetooth controllers lack persistent storage for the device address and instead one can be provided by the boot firmware using the 'local-bd-address' devicetree property.
The Bluetooth bindings clearly says that the address should be specified in little-endian order, but due to a long-standing bug in the Qualcomm driver which reversed the address some bootloaders have been providing the address in big-endian order instead.
The only device out there that should be affected by this is the WCN3991 used in some Chromebooks. To maintain backwards compatibility, mark the current compatible string as deprecated and add a new 'qcom,wcn3991-bt-bdaddr-le' for firmware which conforms with the binding.
--- .../net/bluetooth/qualcomm-bluetooth.yaml | 29 +++++++++++-------- 1 file changed, 17 insertions(+), 12 deletions(-)
Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +17 -12
@@ -15,18 +15,22 @@ description: properties: compatible: - enum: - - qcom,qca2066-bt - - qcom,qca6174-bt - - qcom,qca9377-bt - - qcom,wcn3988-bt - - qcom,wcn3990-bt - - qcom,wcn3991-bt - - qcom,wcn3998-bt - - qcom,qca6390-bt - - qcom,wcn6750-bt - - qcom,wcn6855-bt - - qcom,wcn7850-bt + oneOf: + - enum: + - qcom,qca2066-bt + - qcom,qca6174-bt + - qcom,qca9377-bt + - qcom,wcn3988-bt + - qcom,wcn3990-bt + - qcom,wcn3991-bt-bdaddr-le + - qcom,wcn3998-bt + - qcom,qca6390-bt + - qcom,wcn6750-bt + - qcom,wcn6855-bt + - qcom,wcn7850-bt + - enum: + - qcom,wcn3991-bt + deprecated: true enable-gpios: maxItems: 1
@@ -122,6 +126,7 @@ allOf: - qcom,wcn3988-bt - qcom,wcn3990-bt - qcom,wcn3991-bt + - qcom,wcn3991-bt-bdaddr-le - qcom,wcn3998-bt then: required:
Signature · 1 line
2.43.2
This is an automated email and please do not reply to this email.
Dear Submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.
----- Output -----
error: patch failed: drivers/bluetooth/hci_qca.c:1904
error: drivers/bluetooth/hci_qca.c: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch
Please resolve the issue and submit the patches again.
---
Regards,
Linux Bluetooth
Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
In reply to Johan HovoldQuoted 39 lines · Johan Hovold
Several Qualcomm Bluetooth controllers lack persistent storage for the device address and instead one can be provided by the boot firmware using the 'local-bd-address' devicetree property.
The Bluetooth bindings clearly says that the address should be specified in little-endian order, but due to a long-standing bug in the Qualcomm driver which reversed the address some bootloaders have been providing the address in big-endian order instead.
The only device out there that should be affected by this is the WCN3991 used in some Chromebooks. To maintain backwards compatibility, mark the current compatible string as deprecated and add a new 'qcom,wcn3991-bt-bdaddr-le' for firmware which conforms with the binding.
Signed-off-by Johan Hovold <[email protected]>--- .../net/bluetooth/qualcomm-bluetooth.yaml | 29 +++++++++++-------- 1 file changed, 17 insertions(+), 12 deletions(-)Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +0
-10@@ -15,18 +15,22 @@ description: properties: compatible: - enum: - - qcom,qca2066-bt - - qcom,qca6174-bt - - qcom,qca9377-bt - - qcom,wcn3988-bt - - qcom,wcn3990-bt - - qcom,wcn3991-bt - - qcom,wcn3998-bt - - qcom,qca6390-bt - - qcom,wcn6750-bt
Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml description: · line 25
Quoted 10 lines
Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +8
-2- - qcom,wcn6855-bt - - qcom,wcn7850-bt + oneOf: + - enum: + - qcom,qca2066-bt + - qcom,qca6174-bt + - qcom,qca9377-bt + - qcom,wcn3988-bt + - qcom,wcn3990-bt + - qcom,wcn3991-bt-bdaddr-le
This compatible doesn't describe new hardware kind. As such, I think, the better way would be to continue using qcom,wcn3991-bt compatible string + add some kind of qcom,bt-addr-le property.
Quoted 23 lines
Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +9
-1+ - qcom,wcn3998-bt + - qcom,qca6390-bt + - qcom,wcn6750-bt + - qcom,wcn6855-bt + - qcom,wcn7850-bt + - enum: + - qcom,wcn3991-bt + deprecated: true enable-gpios: maxItems: 1@@ -122,6 +126,7 @@ allOf: - qcom,wcn3988-bt - qcom,wcn3990-bt - qcom,wcn3991-bt + - qcom,wcn3991-bt-bdaddr-le - qcom,wcn3998-bt then: required: --2.43.2
Signature · 2 lines
With best wishes Dmitry
Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
Quoted 17 lines · Dmitry Baryshkov
Quoted 10 lines · Johan Hovold
Several Qualcomm Bluetooth controllers lack persistent storage for the device address and instead one can be provided by the boot firmware using the 'local-bd-address' devicetree property.
The Bluetooth bindings clearly says that the address should be specified in little-endian order, but due to a long-standing bug in the Qualcomm driver which reversed the address some bootloaders have been providing the address in big-endian order instead.
Quoted 5 lines
The only device out there that should be affected by this is the WCN3991 used in some Chromebooks. To maintain backwards compatibility, mark the current compatible string as deprecated and add a new 'qcom,wcn3991-bt-bdaddr-le' for firmware which conforms with the binding.
Quoted 3 lines
This compatible doesn't describe new hardware kind. As such, I think, the better way would be to continue using qcom,wcn3991-bt compatible string + add some kind of qcom,bt-addr-le property.
No, you can't handle backwards compatibility by *adding* a property.
I wanted to avoid doing this, but if we have to support Google's broken boot firmware for these devices, then this is how it needs to be done.
Johan
Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
Quoted 19 lines · Johan Hovold
Quoted 16 lines · Dmitry Baryshkov
Quoted 15 lines · Johan Hovold
Several Qualcomm Bluetooth controllers lack persistent storage for the device address and instead one can be provided by the boot firmware using the 'local-bd-address' devicetree property.
The Bluetooth bindings clearly says that the address should be specified in little-endian order, but due to a long-standing bug in the Qualcomm driver which reversed the address some bootloaders have been providing the address in big-endian order instead.
The only device out there that should be affected by this is the WCN3991 used in some Chromebooks. To maintain backwards compatibility, mark the current compatible string as deprecated and add a new 'qcom,wcn3991-bt-bdaddr-le' for firmware which conforms with the binding.
Quoted 8 lines
Quoted 3 lines
This compatible doesn't describe new hardware kind. As such, I think, the better way would be to continue using qcom,wcn3991-bt compatible string + add some kind of qcom,bt-addr-le property.
No, you can't handle backwards compatibility by *adding* a property.
I wanted to avoid doing this, but if we have to support Google's broken boot firmware for these devices, then this is how it needs to be done.
One hardware compat string per hardware type.
Signature · 2 lines
With best wishes Dmitry
Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
Quoted 13 lines · Dmitry Baryshkov
Quoted 12 lines · Johan Hovold
Quoted 10 lines · Dmitry Baryshkov
Quoted 5 lines · Johan Hovold
The only device out there that should be affected by this is the WCN3991 used in some Chromebooks. To maintain backwards compatibility, mark the current compatible string as deprecated and add a new 'qcom,wcn3991-bt-bdaddr-le' for firmware which conforms with the binding.
This compatible doesn't describe new hardware kind. As such, I think, the better way would be to continue using qcom,wcn3991-bt compatible string + add some kind of qcom,bt-addr-le property.
Quoted 6 lines
Quoted 4 lines
No, you can't handle backwards compatibility by *adding* a property.
I wanted to avoid doing this, but if we have to support Google's broken boot firmware for these devices, then this is how it needs to be done.
One hardware compat string per hardware type.
Again, no. Not when there is an incompatible change in the binding. Then we add a new compatible string and deprecate the old binding.
Johan
Rob Herring
maintainerRe: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
In reply to Johan HovoldQuoted 18 lines · Johan Hovold
Quoted 16 lines · Dmitry Baryshkov
Quoted 15 lines · Johan Hovold
Several Qualcomm Bluetooth controllers lack persistent storage for the device address and instead one can be provided by the boot firmware using the 'local-bd-address' devicetree property.
The Bluetooth bindings clearly says that the address should be specified in little-endian order, but due to a long-standing bug in the Qualcomm driver which reversed the address some bootloaders have been providing the address in big-endian order instead.
The only device out there that should be affected by this is the WCN3991 used in some Chromebooks. To maintain backwards compatibility, mark the current compatible string as deprecated and add a new 'qcom,wcn3991-bt-bdaddr-le' for firmware which conforms with the binding.
Quoted 5 lines
Quoted 3 lines
This compatible doesn't describe new hardware kind. As such, I think, the better way would be to continue using qcom,wcn3991-bt compatible string + add some kind of qcom,bt-addr-le property.
No, you can't handle backwards compatibility by *adding* a property.
But you could add a property for the not broken case. That's a bit odd, but so is your compatible.
Quoted 2 lines
I wanted to avoid doing this, but if we have to support Google's broken boot firmware for these devices, then this is how it needs to be done.
Don't Chromebooks update everything together. So maybe we don't care in this case?
Rob
Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
Quoted 10 lines · Rob Herring
Quoted 9 lines · Johan Hovold
Quoted 7 lines · Dmitry Baryshkov
Quoted 5 lines · Johan Hovold
The only device out there that should be affected by this is the WCN3991 used in some Chromebooks. To maintain backwards compatibility, mark the current compatible string as deprecated and add a new 'qcom,wcn3991-bt-bdaddr-le' for firmware which conforms with the binding.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
This compatible doesn't describe new hardware kind. As such, I think, the better way would be to continue using qcom,wcn3991-bt compatible string + add some kind of qcom,bt-addr-le property.
No, you can't handle backwards compatibility by *adding* a property.
But you could add a property for the not broken case. That's a bit odd, but so is your compatible.
Sure, we could have a property that we only add for wcn3991-bt going forward.
But we can't go back in time and add this property to all devicetrees and say that 'local-bd-address' is big endian unless that property is present (as that would leave all the non-wcn3991 devicetrees broken).
Quoted 5 lines
Quoted 2 lines
I wanted to avoid doing this, but if we have to support Google's broken boot firmware for these devices, then this is how it needs to be done.
Don't Chromebooks update everything together. So maybe we don't care in this case?
That was my hope, but Matthias seemed to suggest that we need to continue supporting the current (broken) binding because doing such a coordinated update may be easier said than done:
https://lore.kernel.org/lkml/[email protected]/
A new compatible string (or one-off property) would allow them do make a change when they are ready (e.g. by only updating the devicetrees after all boot firmware has been patched and pushed out).
Johan
Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
Hi,
Quoted 4 lines · Johan Hovold
Quoted 4 lines
Quoted 3 lines
I wanted to avoid doing this, but if we have to support Google's broken boot firmware for these devices, then this is how it needs to be done.
Quoted 8 lines
Quoted 2 lines
Don't Chromebooks update everything together. So maybe we don't care in this case?
That was my hope, but Matthias seemed to suggest that we need to continue supporting the current (broken) binding because doing such a coordinated update may be easier said than done:
Chromebooks update kernel and devicetree together, but not firmware. Firmware is relatively hard to get updated trying to have kernel and firmware updates coordinated at the exact same time has challenges. This would further be complicated by the fact that firmware qualification for each variant happens on its own timeline.
Quoted 3 lines
A new compatible string (or one-off property) would allow them do make a change when they are ready (e.g. by only updating the devicetrees after all boot firmware has been patched and pushed out).
I have no real opinion about the exact way this is solved so happy to let DT folks decide on how they want this. I will note, however, that device trees are never shipped separately and thus we have no intrinsic need for DT backward compatbility here. It would be OK from a ChromeOS perspective to add a property or compatible string for the broken case.
-Doug
Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
Hi,
Quoted 28 lines · Doug Anderson
Hi,
Quoted 4 lines · Johan Hovold
Quoted 4 lines
Quoted 3 lines
I wanted to avoid doing this, but if we have to support Google's broken boot firmware for these devices, then this is how it needs to be done.
Quoted 8 lines
Quoted 2 lines
Don't Chromebooks update everything together. So maybe we don't care in this case?
That was my hope, but Matthias seemed to suggest that we need to continue supporting the current (broken) binding because doing such a coordinated update may be easier said than done:
Chromebooks update kernel and devicetree together, but not firmware. Firmware is relatively hard to get updated trying to have kernel and firmware updates coordinated at the exact same time has challenges. This would further be complicated by the fact that firmware qualification for each variant happens on its own timeline.
Quoted 3 lines
A new compatible string (or one-off property) would allow them do make a change when they are ready (e.g. by only updating the devicetrees after all boot firmware has been patched and pushed out).
Quoted 6 lines
I have no real opinion about the exact way this is solved so happy to let DT folks decide on how they want this. I will note, however, that device trees are never shipped separately and thus we have no intrinsic need for DT backward compatbility here. It would be OK from a ChromeOS perspective to add a property or compatible string for the broken case.
Actually, I should probably say more about this to make it clear how it works.
Chromebooks ship the kernel as a FIT image which bundles the kernel and device trees together. The firmware looks at all the bundled device trees and picks the proper one based on the board name, revision, and SKU ID. The firmware then looks for the bluetooth node (I believe it finds it from the "aliases" section) and adds the MAC address there.
...so we could update the DT to add a property (if that's desired) even if we don't update the firmware.
-Doug
Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
Quoted 22 lines · Doug Anderson
Quoted 10 lines · Doug Anderson
Quoted 3 lines
A new compatible string (or one-off property) would allow them do make a change when they are ready (e.g. by only updating the devicetrees after all boot firmware has been patched and pushed out).
I have no real opinion about the exact way this is solved so happy to let DT folks decide on how they want this. I will note, however, that device trees are never shipped separately and thus we have no intrinsic need for DT backward compatbility here. It would be OK from a ChromeOS perspective to add a property or compatible string for the broken case.
Actually, I should probably say more about this to make it clear how it works.
Chromebooks ship the kernel as a FIT image which bundles the kernel and device trees together. The firmware looks at all the bundled device trees and picks the proper one based on the board name, revision, and SKU ID. The firmware then looks for the bluetooth node (I believe it finds it from the "aliases" section) and adds the MAC address there.
Quoted 2 lines
...so we could update the DT to add a property (if that's desired) even if we don't update the firmware.
Thanks for the details. Sounds like we could get away with adding a new property for the broken firmware in this case, which should resolve this nicely without having to deprecate anything.
Could you carry such a devicetree patch out-of-tree until the firmware has been fixed?
Johan
Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
Hi,
Quoted 27 lines · Johan Hovold
Quoted 22 lines · Doug Anderson
Quoted 10 lines · Doug Anderson
Quoted 3 lines
A new compatible string (or one-off property) would allow them do make a change when they are ready (e.g. by only updating the devicetrees after all boot firmware has been patched and pushed out).
I have no real opinion about the exact way this is solved so happy to let DT folks decide on how they want this. I will note, however, that device trees are never shipped separately and thus we have no intrinsic need for DT backward compatbility here. It would be OK from a ChromeOS perspective to add a property or compatible string for the broken case.
Actually, I should probably say more about this to make it clear how it works.
Chromebooks ship the kernel as a FIT image which bundles the kernel and device trees together. The firmware looks at all the bundled device trees and picks the proper one based on the board name, revision, and SKU ID. The firmware then looks for the bluetooth node (I believe it finds it from the "aliases" section) and adds the MAC address there.
Quoted 2 lines
...so we could update the DT to add a property (if that's desired) even if we don't update the firmware.
Quoted 6 lines
Thanks for the details. Sounds like we could get away with adding a new property for the broken firmware in this case, which should resolve this nicely without having to deprecate anything.
Could you carry such a devicetree patch out-of-tree until the firmware has been fixed?
IMO we shouldn't try to fix the firmware at all. Given the fact that it took me a year to get a firmware uprev completed for one trogdor variant for fixes that actually had functional impact, it's possible we'll never actually get an uprev completed that includes this fix or it will happen years from now when nobody remembers about it. I'm also certain this whole issue will also cause a bunch of debugging over the years if we try to fix it in firmware like that. There are cases where people end up running with old firmware since the developer workflow doesn't automatically update it.
The handling should be added upstream and we should just accept that the trogdor firmware gets it backward.
-Doug
Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr
Quoted 20 lines · Doug Anderson
Quoted 8 lines · Johan Hovold
On Mon, Mar 18, 2024 at 08:31:09AM -0700, Doug Anderson wrote:
Thanks for the details. Sounds like we could get away with adding a new property for the broken firmware in this case, which should resolve this nicely without having to deprecate anything.
Could you carry such a devicetree patch out-of-tree until the firmware has been fixed?
IMO we shouldn't try to fix the firmware at all. Given the fact that it took me a year to get a firmware uprev completed for one trogdor variant for fixes that actually had functional impact, it's possible we'll never actually get an uprev completed that includes this fix or it will happen years from now when nobody remembers about it. I'm also certain this whole issue will also cause a bunch of debugging over the years if we try to fix it in firmware like that. There are cases where people end up running with old firmware since the developer workflow doesn't automatically update it.
Quoted 2 lines
The handling should be added upstream and we should just accept that the trogdor firmware gets it backward.
Fair enough.
Rob, are you OK with adding a 'qcom,local-bd-address-broken' or similarly named property to indicate that the boot firmware passes the address in the wrong order?
I'd then add that property to sc7180-trogdor.dtsi in mainline.
Johan
PATCH v2 2/4 Bluetooth: add quirk for broken address properties
In reply to Johan HovoldSome Bluetooth controllers lack persistent storage for the device address and instead one can be provided by the boot firmware using the 'local-bd-address' devicetree property.
The Bluetooth devicetree bindings clearly states that the address should be specified in little-endian order, but due to a long-standing bug in the Qualcomm driver which reversed the address some bootloaders have been providing the address in big-endian order instead.
Add a new quirk that can be used to mark deprecated compatible strings that expect such broken devicetree properties and use it to reverse the address when parsing the property so that the underlying driver bug can be fixed.
--- include/net/bluetooth/hci.h | 10 ++++++++++ net/bluetooth/hci_sync.c | 5 ++++- 2 files changed, 14 insertions(+), 1 deletion(-)
include/net/bluetooth/hci.h +10 -0
@@ -176,6 +176,16 @@ enum {*/ HCI_QUIRK_USE_BDADDR_PROPERTY , +/* When this quirk is set, the Bluetooth Device Address provided by +* the 'local-bd-address' fwnode property is incorrectly specified in +* big-endian order. +* +* This quirk can be set before hci_register_dev is called or +* during the hdev->setup vendor callback and must only be used for +* deprecated compatible strings. +*/ + HCI_QUIRK_BDADDR_PROPERTY_BROKEN, +/* When this quirk is set, the duplicate filtering during * scanning is based on Bluetooth devices addresses. To allow * RSSI based updates, restart scanning if needed.
net/bluetooth/hci_sync.c +4 -1
@@ -3215,7 +3215,10 @@ static void hci_dev_get_bd_addr_from_property(struct hci_dev *hdev)if (ret <0 || !bacmp (&ba,BDADDR_ANY ))return ; -bacpy (&hdev->public_addr, &ba); +if (test_bit (HCI_QUIRK_BDADDR_PROPERTY_BROKEN , &hdev->quirks)) +baswap (&hdev->public_addr, &ba); +else +bacpy (&hdev->public_addr, &ba); }struct hci_init_stage {
Signature · 1 line
2.43.2
PATCH v2 3/4 Bluetooth: qca: fix device-address endianness
In reply to Johan HovoldThe WCN6855 firmware on the Lenovo ThinkPad X13s expects the Bluetooth device address in big-endian order when setting it using the EDL_WRITE_BD_ADDR_OPCODE command.
Presumably, this is the case for all non-ROME devices which all use the EDL_WRITE_BD_ADDR_OPCODE command for this (unlike the ROME devices which use a different command and expect the address in little-endian order).
Reverse the little-endian address before setting it to make sure that the address can be configured using tools like btmgmt or using the 'local-bd-address' devicetree property.
Note that this can potentially break systems with boot firmware which has started relying on the broken behaviour and is incorrectly passing the address via devicetree in big-endian order.
--- drivers/bluetooth/btqca.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/bluetooth/btqca.c +6 -2
@@ -826,11 +826,15 @@ EXPORT_SYMBOL_GPL(qca_uart_setup);int qca_set_bdaddr (struct hci_dev *hdev,const bdaddr_t *bdaddr) { +bdaddr_t bdaddr_swapped;struct sk_buff *skb;int err; - skb =__hci_cmd_sync_ev (hdev,EDL_WRITE_BD_ADDR_OPCODE ,6 , bdaddr, -HCI_EV_VENDOR ,HCI_INIT_TIMEOUT ); +baswap (&bdaddr_swapped, bdaddr); + + skb =__hci_cmd_sync_ev (hdev,EDL_WRITE_BD_ADDR_OPCODE ,6 , + &bdaddr_swapped,HCI_EV_VENDOR , +HCI_INIT_TIMEOUT );if (IS_ERR (skb)) { err =PTR_ERR (skb);bt_dev_err (hdev,"QCA Change address cmd failed (%d)" , err);
Signature · 1 line
2.43.2
PATCH v2 4/4 Bluetooth: qca: fix wcn3991 'local-bd-address' endianness
In reply to Johan HovoldDue to a long-standing bug in the Qualcomm Bluetooth driver, the device address has so far been reversed when configuring the controller.
This has led to one vendor reversing the address provided by the boot firmware using the 'local-bd-address' devicetree property.
The only device affected by this should be the WCN3991 used in some Chromebooks. The corresponding compatible string has now been deprecated so that the underlying driver bug can be fixed without breaking backwards compatibility.
Set the HCI_QUIRK_BDADDR_PROPERTY_BROKEN quirk for the deprecated compatible string and add the new 'qcom,wcn3991-bt-bdaddr-le' string to the match table for boot firmware that conforms with the binding.
--- drivers/bluetooth/hci_qca.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/bluetooth/hci_qca.c +11 -0
@@ -1904,6 +1904,16 @@ static int qca_setup(struct hci_uart *hu)case QCA_WCN6855 :case QCA_WCN7850 :set_bit (HCI_QUIRK_USE_BDADDR_PROPERTY , &hdev->quirks); + +if (soc_type ==QCA_WCN3991 ) { +struct device *dev =GET_HCIDEV_DEV (hdev); + +if (device_is_compatible (dev,"qcom,wcn3991-bt" )) { +set_bit (HCI_QUIRK_BDADDR_PROPERTY_BROKEN , + &hdev->quirks); + } + } +hci_set_aosp_capable (hdev); ret =qca_read_soc_version (hdev, &ver, soc_type);
@@ -2597,6 +2607,7 @@ static const struct of_device_id qca_bluetooth_of_match[] = { { .compatible = "qcom,wcn3988-bt", .data = &qca_soc_data_wcn3988}, { .compatible = "qcom,wcn3990-bt", .data = &qca_soc_data_wcn3990}, { .compatible = "qcom,wcn3991-bt", .data = &qca_soc_data_wcn3991}, + { .compatible = "qcom,wcn3991-bt-bdaddr-le", .data = &qca_soc_data_wcn3991}, { .compatible = "qcom,wcn3998-bt", .data = &qca_soc_data_wcn3998}, { .compatible = "qcom,wcn6750-bt", .data = &qca_soc_data_wcn6750}, { .compatible = "qcom,wcn6855-bt", .data = &qca_soc_data_wcn6855},
Signature · 1 line
2.43.2