Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-2594-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Mon, 18 Mar 2024 17:34:50 +0100
From: Johan Hovold <johan@kernel.org>
To: Doug Anderson <dianders@google.com>, Rob Herring <robh@kernel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Johan Hovold <johan+linaro@kernel.org>,
	Marcel Holtmann <marcel@holtmann.org>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	Matthias Kaehlcke <mka@chromium.org>,
	Bjorn Andersson <quic_bjorande@quicinc.com>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	linux-bluetooth@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991
 compatible to fix bd_addr
Message-ID: <ZfhtKpwzt9ukOL6J@hovoldconsulting.com>
References: <20240318110855.31954-1-johan+linaro@kernel.org>
 <20240318110855.31954-2-johan+linaro@kernel.org>
 <CAA8EJprywWbdoyfAbys=0WzEdAkp0UK1fzzCPzxKRjyk9DrC6Q@mail.gmail.com>
 <Zfg--2_NMPSPTxK-@hovoldconsulting.com>
 <20240318144806.GA3963554-robh@kernel.org>
 <ZfhZffrZXwtKgZ13@hovoldconsulting.com>
 <CAD=FV=UpuD7Lq0DxSZAGpL4Mi2uxy9HNt3V3FZq7Y3p--gbMrg@mail.gmail.com>
 <CAD=FV=WCzrh926mkiyBnKRG_+KGuOkGN6v0DgPiXhQCD3PSQ9w@mail.gmail.com>
 <Zfhh-4wEg4O4Xqeu@hovoldconsulting.com>
 <CAD=FV=XpOf8ZcqROgwFX9bs7B1gNGDDVOYezBztLJEy6U3AOnA@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAD=FV=XpOf8ZcqROgwFX9bs7B1gNGDDVOYezBztLJEy6U3AOnA@mail.gmail.com>

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@kernel.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