Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: Johan Hovold <johan+linaro@kernel.org>,
	Marcel Holtmann <marcel@holtmann.org>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Bjorn Andersson <quic_bjorande@quicinc.com>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	linux-bluetooth@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	Balakrishna Godavarthi <quic_bgodavar@quicinc.com>,
	Doug Anderson <dianders@google.com>,
	Stephen Boyd <swboyd@google.com>
Subject: Re: [PATCH] Bluetooth: qca: fix device-address endianness
Date: Wed, 10 Jan 2024 09:12:06 +0100	[thread overview]
Message-ID: <ZZ5RVpL88XNbgKIy@hovoldconsulting.com> (raw)
In-Reply-To: <ZZ2IOQEekFffJoHQ@google.com>

On Tue, Jan 09, 2024 at 05:54:01PM +0000, Matthias Kaehlcke wrote:
> On Tue, Jan 09, 2024 at 06:12:26PM +0100, Johan Hovold wrote:

> > That depends on in what way the current devices are broken.
> > 
> > Any machines that correctly specify their address in little-endian order
> > in the devicetree would no longer be configured using the wrong address.
> > So no problem there (except requiring users to re-pair their gadgets).
> > 
> > And tools like btgmt is broken on all of these Qualcomm machine in any
> > case and would now start working as expected. So no problem there either
> > (unless user space had adapted an inverted the addresses to btmgmt).
> > 
> > So the first question is whether there actually is any boot firmware out
> > there which passes the BD_ADDR in reverse order?
> 
> Yes, (at least) the boot firmware for sc7180-trogdor devices.
> 
> hexdump -C /proc/device-tree/soc\@0/geniqup\@8c0000/serial\@88c000/bluetooth/local-bd-address
> 00000000  8c fd f0 40 15 dc

Indeed, this should have been LE order.

> hciconfig
> hci0:   Type: Primary  Bus: UART
>         BD Address: 8C:FD:F0:40:15:DC  ACL MTU: 1024:8  SCO MTU: 240:8
>         UP RUNNING 
>         RX bytes:1700 acl:0 sco:0 events:95 errors:0
>         TX bytes:128949 acl:0 sco:0 commands:578 errors:0

And any user space tool overriding the address would currently need to
provide the address in reverse order on Qualcomm platforms like this
one (e.g. if generating the address for privacy reasons).
 
> > > I suggest adding a quirk like 'local-bd-address-msb-quirk' or
> > > 'qcom,local-bd-address-msb-quirk' to make sure existing devices keep
> > > working properly.
> > 
> > I don't think that would work. If this is something that we really need
> > to handle, then there's probably no way around introducing new
> > compatible strings for boot firmware that isn't broken while maintaining
> > the current broken behaviour with respect to 'local-bd-address' for some
> > of the current ones.
> 
> I think it should work for sc7180-trogdor. For these devices the device tree
> is bundled with the kernel image and can be updated. That might not be true
> for other devices though.

Thanks for confirming.

I'm still hoping we can get away with not having to add quirks to
Bluetooth core for broken Qualcomm boot firmware. Let's see if anyone
knows of a use case that makes that impossible to avoid.

Johan

  reply	other threads:[~2024-01-10  8:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-27 18:03 [PATCH] Bluetooth: qca: fix device-address endianness Johan Hovold
2023-12-28  6:08 ` Nikita Travkin
2024-01-09 16:50 ` Matthias Kaehlcke
2024-01-09 17:12   ` Johan Hovold
2024-01-09 17:54     ` Matthias Kaehlcke
2024-01-10  8:12       ` Johan Hovold [this message]
2024-01-17 21:52         ` Doug Anderson
2024-01-18  8:17           ` Johan Hovold
2024-01-17 22:49         ` Luiz Augusto von Dentz
2024-01-18  8:40           ` Johan Hovold
2024-01-18 15:30             ` Luiz Augusto von Dentz
2024-01-19 15:59               ` Johan Hovold
2024-02-13 14:41 ` Johan Hovold
2024-02-13 15:55   ` Matthias Kaehlcke
2024-02-13 16:03     ` Johan Hovold
2024-02-13 16:18       ` Matthias Kaehlcke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZZ5RVpL88XNbgKIy@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=dianders@google.com \
    --cc=johan+linaro@kernel.org \
    --cc=johan.hedberg@gmail.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=mka@chromium.org \
    --cc=quic_bgodavar@quicinc.com \
    --cc=quic_bjorande@quicinc.com \
    --cc=stable@vger.kernel.org \
    --cc=swboyd@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox