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 08:26:26 -0700
From: Doug Anderson <dianders@...gle.com>
To: Johan Hovold <johan@...nel.org>
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

Hi,

On Mon, Mar 18, 2024 at 8:10 AM Johan Hovold <johan@...nel.org> wrote:
>
> > > 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?
>
> That was my hope, but Matthias seemed to suggest that we need to
> continue supporting the current (broken) binding because doing such a
> coordinated update may be easier said than done:
>
>         https://lore.kernel.org/lkml/ZcuQ2qRX0zsLSVRL@google.com/

Chromebooks update kernel and devicetree together, but not firmware.
Firmware is relatively hard to get updated trying to have kernel and
firmware updates coordinated at the exact same time has challenges.
This would further be complicated by the fact that firmware
qualification for each variant happens on its own timeline.


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

-Doug

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ