Re: [PATCH] Revert "Bluetooth: hci_qca: Set BDA quirk bit if fwnode exists in DT"

[Johan Hovold <johan@kernel.org>]

On Thu, Mar 14, 2024 at 10:30:36AM -0400, Luiz Augusto von Dentz wrote:
> On Thu, Mar 14, 2024 at 4:44 AM Johan Hovold <johan+linaro@kernel.org> wrote:

> > This reverts commit 7dcd3e014aa7faeeaf4047190b22d8a19a0db696.
> >
> > Qualcomm Bluetooth controllers like WCN6855 do not have persistent
> > storage for the Bluetooth address and must therefore start as
> > unconfigured to allow the user to set a valid address unless one has
> > been provided by the boot firmware in the devicetree.
> >
> > A recent change snuck into v6.8-rc7 and incorrectly started marking the
> > default (non-unique) address as valid. This specifically also breaks the
> > Bluetooth setup for some user of the Lenovo ThinkPad X13s.
> >
> > Note that this is the second time Qualcomm breaks the driver this way
> > and that this was fixed last year by commit 6945795bc81a ("Bluetooth:
> > fix use-bdaddr-property quirk"), which also has some further details.
> >
> > Fixes: 7dcd3e014aa7 ("Bluetooth: hci_qca: Set BDA quirk bit if fwnode exists in DT")
> > Cc: stable@vger.kernel.org      # 6.8
> > Cc: Janaki Ramaiah Thota <quic_janathot@quicinc.com>
> > Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
> 
> Well I guess I will need to start asking for evidence that this works
> on regular Linux distros then, because it looks like that is not the
> environment Janaki and others Qualcomm folks are testing with.
> 
> What I probably would consider as evidence is bluetoothd logs showing
> that the controller has been configured correctly or perhaps there is
> a simpler way?

Well, in this case we actually want the controller to remain
unconfigured (e.g. to avoid having every user of the X13s unknowingly
use the same default address). 

I'm not sure why Qualcomm insists on breaking these quirks, but I guess
they just haven't understood why they exist. It's of course convenient
to be able to use the default address during development without first
having to provide an address, but that's not a valid reason to break the
driver.

From what I hear the Qualcomm developers only care about Android and I
believe they have some out-of-tree hack for retrieving the device
address directly from the rootfs.

For the X13s, and as I think I've mentioned before, we have been trying
to get Qualcomm to tell us how to access the assigned addresses that are
stored in some secure world storage so that we can set it directly from
the driver. But until we figure that out, users will need to continue
setting the address manually.

Johan