linux-kernel - Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 18 Mar 2024 16:47:07 +0100
From: Johan Hovold <johan@...nel.org>
To: Doug Anderson <dianders@...gle.com>
Cc: Rob Herring <robh@...nel.org>,
	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:31:09AM -0700, Doug Anderson wrote:
> On Mon, Mar 18, 2024 at 8:26 AM Doug Anderson <dianders@...gle.com> wrote:

> > > A new compatible string (or one-off property) would allow them do make a
> > > change when they are ready (e.g. by only updating the devicetrees after
> > > all boot firmware has been patched and pushed out).
> >
> > I have no real opinion about the exact way this is solved so happy to
> > let DT folks decide on how they want this. I will note, however, that
> > device trees are never shipped separately and thus we have no
> > intrinsic need for DT backward compatbility here. It would be OK from
> > a ChromeOS perspective to add a property or compatible string for the
> > broken case.
> 
> Actually, I should probably say more about this to make it clear how it works.
> 
> Chromebooks ship the kernel as a FIT image which bundles the kernel
> and device trees together. The firmware looks at all the bundled
> device trees and picks the proper one based on the board name,
> revision, and SKU ID. The firmware then looks for the bluetooth node
> (I believe it finds it from the "aliases" section) and adds the MAC
> address there.
> 
> ...so we could update the DT to add a property (if that's desired)
> even if we don't update the firmware.

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?

Johan