diff mbox series

[v3,2/5] Bluetooth: add quirk for broken address properties

Message ID 20240319152926.1288-3-johan+linaro@kernel.org (mailing list archive)
State Superseded
Headers show
Series Bluetooth: qca: fix device-address endianness | expand

Checks

Context Check Description
tedd_an/pre-ci_am success Success

Commit Message

Johan Hovold March 19, 2024, 3:29 p.m. UTC
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@vger.kernel.org      # 5.1
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
---
 include/net/bluetooth/hci.h | 9 +++++++++
 net/bluetooth/hci_sync.c    | 5 ++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

Comments

Doug Anderson March 19, 2024, 4:10 p.m. UTC | #1
Hi,

On Tue, Mar 19, 2024 at 8:29 AM Johan Hovold <johan+linaro@kernel.org> 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@vger.kernel.org      # 5.1
> Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
> ---
>  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.

Reviewed-by: Douglas Anderson <dianders@chromium.org>
Konrad Dybcio March 19, 2024, 4:16 p.m. UTC | #2
On 3/19/24 17:10, Doug Anderson wrote:
> Hi,
> 
> On Tue, Mar 19, 2024 at 8:29 AM Johan Hovold <johan+linaro@kernel.org> 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@vger.kernel.org      # 5.1
>> Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
>> ---
>>   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
Johan Hovold March 19, 2024, 4:26 p.m. UTC | #3
On Tue, Mar 19, 2024 at 09:10:23AM -0700, Doug Anderson wrote:
> On Tue, Mar 19, 2024 at 8:29 AM Johan Hovold <johan+linaro@kernel.org> wrote:

> > +       /* 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.

So, same reasoning here, this it not some quirk that people should go
around setting without first considering to fix their boot firmware.

Johan
Dmitry Baryshkov March 19, 2024, 5:01 p.m. UTC | #4
On Tue, 19 Mar 2024 at 18:26, Johan Hovold <johan@kernel.org> wrote:
>
> On Tue, Mar 19, 2024 at 09:10:23AM -0700, Doug Anderson wrote:
> > On Tue, Mar 19, 2024 at 8:29 AM Johan Hovold <johan+linaro@kernel.org> wrote:
>
> > > +       /* 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.
>
> So, same reasoning here, this it not some quirk that people should go
> around setting without first considering to fix their boot firmware.

The address can be considered broken in many different ways. The name
should still be descriptive enough. If you want to specify that it is
a broken behaviour, please consider something like BROKEN_BE.
Luiz Augusto von Dentz March 19, 2024, 5:02 p.m. UTC | #5
Hi,

On Tue, Mar 19, 2024 at 4:26 PM Johan Hovold <johan@kernel.org> wrote:
>
> On Tue, Mar 19, 2024 at 09:10:23AM -0700, Doug Anderson wrote:
> > On Tue, Mar 19, 2024 at 8:29 AM Johan Hovold <johan+linaro@kernel.org> wrote:
>
> > > +       /* 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.
>
> So, same reasoning here, this it not some quirk that people should go
> around setting without first considering to fix their boot firmware.

Or we just change its meaning to say what byteorder is the BDADDR e.g:
HCI_QUIRK_BDADDR_PROPERTY_BYTEORDER=be

> Johan
Luiz Augusto von Dentz March 19, 2024, 5:04 p.m. UTC | #6
On Tue, Mar 19, 2024 at 5:02 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
>  Hi,
>
> On Tue, Mar 19, 2024 at 4:26 PM Johan Hovold <johan@kernel.org> wrote:
> >
> > On Tue, Mar 19, 2024 at 09:10:23AM -0700, Doug Anderson wrote:
> > > On Tue, Mar 19, 2024 at 8:29 AM Johan Hovold <johan+linaro@kernel.org> wrote:
> >
> > > > +       /* 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.
> >
> > So, same reasoning here, this it not some quirk that people should go
> > around setting without first considering to fix their boot firmware.
>
> Or we just change its meaning to say what byteorder is the BDADDR e.g:
> HCI_QUIRK_BDADDR_PROPERTY_BYTEORDER=be

Ah just ignore, it is a flag not really a property that can assume
different values.

> > Johan
>
>
>
> --
> Luiz Augusto von Dentz
Johan Hovold March 19, 2024, 5:38 p.m. UTC | #7
On Tue, Mar 19, 2024 at 07:01:57PM +0200, Dmitry Baryshkov wrote:
> On Tue, 19 Mar 2024 at 18:26, Johan Hovold <johan@kernel.org> wrote:
> >
> > On Tue, Mar 19, 2024 at 09:10:23AM -0700, Doug Anderson wrote:
> > > On Tue, Mar 19, 2024 at 8:29 AM Johan Hovold <johan+linaro@kernel.org> wrote:
> >
> > > > +       /* 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.
> >
> > So, same reasoning here, this it not some quirk that people should go
> > around setting without first considering to fix their boot firmware.
> 
> The address can be considered broken in many different ways. The name
> should still be descriptive enough. If you want to specify that it is
> a broken behaviour, please consider something like BROKEN_BE.

I doubt that Qualcomm will be able come up with another way to break the
address property. They'd have to try real hard.

And this is an internal define which can be changed at any time. There's
also some worth in keeping it aligned with the DT property, which I'm
more open to renaming (e.g. if the DT maintainers thinks dropping the
vendor prefix makes sense).

The alternative I considered but rejected was something like
"local-bd-address-be" as that would be too neutral.

Perhaps "local-bd-address-reversed" would at least signal that something
is backwards, but I still fear that that may be too subtle.

Johan
diff mbox series

Patch

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,
+
 	/* 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.
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 5716345a26df..283ae8edc1e5 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -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 {