On 3/19/24 17:10, Doug Anderson wrote:
Hi, On Tue, Mar 19, 2024 at 8:29 AM Johan Hovold <johan+linaro@xxxxxxxxxx> wrote:Some 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 boot firmware has been providing the address in big-endian order instead. Add a new quirk that can be set on platforms with broken firmware and use it to reverse the address when parsing the property so that the underlying driver bug can be fixed. Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address") Cc: stable@xxxxxxxxxxxxxxx # 5.1 Signed-off-by: Johan Hovold <johan+linaro@xxxxxxxxxx> --- include/net/bluetooth/hci.h | 9 +++++++++ net/bluetooth/hci_sync.c | 5 ++++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index bdee5d649cc6..191077d8d578 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -176,6 +176,15 @@ 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. + */ + HCI_QUIRK_BDADDR_PROPERTY_BROKEN,Like with the binding, I feel like "HCI_QUIRK_BDADDR_PROPERTY_BACKWARDS" or "HCI_QUIRK_BDADDR_PROPERTY_SWAPPED" would be more documenting but I don't feel strongly.
Yeah, I thought the same.. and the binding, perhaps could be generic, as I have a strong suspicion Qualcomm is not the only vendor who made such oopsies.. Konrad
