[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zfg--2_NMPSPTxK-@hovoldconsulting.com>
Date: Mon, 18 Mar 2024 14:17:47 +0100
From: Johan Hovold <johan@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Johan Hovold <johan+linaro@...nel.org>,
Marcel Holtmann <marcel@...tmann.org>,
Luiz Augusto von Dentz <luiz.dentz@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Johan Hedberg <johan.hedberg@...il.com>,
Matthias Kaehlcke <mka@...omium.org>,
Doug Anderson <dianders@...gle.com>,
Bjorn Andersson <quic_bjorande@...cinc.com>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
linux-bluetooth@...r.kernel.org, linux-arm-msm@...r.kernel.org,
netdev@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991
compatible to fix bd_addr
On Mon, Mar 18, 2024 at 03:00:40PM +0200, Dmitry Baryshkov wrote:
> On Mon, 18 Mar 2024 at 13:09, Johan Hovold <johan+linaro@...nel.org> wrote:
> >
> > 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.
> 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
Powered by blists - more mailing lists