[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZfhtKpwzt9ukOL6J@hovoldconsulting.com>
Date: Mon, 18 Mar 2024 17:34:50 +0100
From: Johan Hovold <johan@...nel.org>
To: Doug Anderson <dianders@...gle.com>, Rob Herring <robh@...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>,
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 08:58:40AM -0700, Doug Anderson wrote:
> On Mon, Mar 18, 2024 at 8:47 AM Johan Hovold <johan@...nel.org> wrote:
> > On Mon, Mar 18, 2024 at 08:31:09AM -0700, Doug Anderson wrote:
> > Thanks for the details. Sounds like we could get away with adding a new
> > property for the broken firmware in this case, which should resolve this
> > nicely without having to deprecate anything.
> >
> > Could you carry such a devicetree patch out-of-tree until the firmware
> > has been fixed?
>
> IMO we shouldn't try to fix the firmware at all. Given the fact that
> it took me a year to get a firmware uprev completed for one trogdor
> variant for fixes that actually had functional impact, it's possible
> we'll never actually get an uprev completed that includes this fix or
> it will happen years from now when nobody remembers about it. I'm also
> certain this whole issue will also cause a bunch of debugging over the
> years if we try to fix it in firmware like that. There are cases where
> people end up running with old firmware since the developer workflow
> doesn't automatically update it.
>
> The handling should be added upstream and we should just accept that
> the trogdor firmware gets it backward.
Fair enough.
Rob, are you OK with adding a 'qcom,local-bd-address-broken' or
similarly named property to indicate that the boot firmware passes the
address in the wrong order?
I'd then add that property to sc7180-trogdor.dtsi in mainline.
Johan
Powered by blists - more mailing lists