[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240318144806.GA3963554-robh@kernel.org>
Date: Mon, 18 Mar 2024 09:48:06 -0500
From: Rob Herring <robh@...nel.org>
To: Johan Hovold <johan@...nel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Johan Hovold <johan+linaro@...nel.org>,
Marcel Holtmann <marcel@...tmann.org>,
Luiz Augusto von Dentz <luiz.dentz@...il.com>,
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 02:17:47PM +0100, Johan Hovold wrote:
> 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.
But you could add a property for the not broken case. That's a bit odd,
but so is your compatible.
> 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.
Don't Chromebooks update everything together. So maybe we don't care in
this case?
Rob
Powered by blists - more mailing lists