linux-kernel - Re: [PATCH 1/4] arm64: dts: qcom: sdm845-oneplus: Update firmware paths

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] [day] [month] [year] [list]

Message-ID: <nv3uiez57xmrfpcpkvqitvnfrbs6suuqor3a3trwugpvqxvr2j@6loizlgt5l6b>
Date: Wed, 24 Dec 2025 17:14:38 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Akhil P Oommen <akhilpo@....qualcomm.com>
Cc: David Heidelberg <david@...t.cz>, Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] arm64: dts: qcom: sdm845-oneplus: Update firmware
 paths

On Wed, Dec 24, 2025 at 06:48:53PM +0530, Akhil P Oommen wrote:
> On 12/23/2025 1:21 AM, David Heidelberg wrote:
> > On 22/12/2025 20:31, Akhil P Oommen wrote:
> >> On 12/23/2025 12:35 AM, David Heidelberg via B4 Relay wrote:
> >>> From: David Heidelberg <david@...t.cz>
> >>>
> >>> Conform to the new firmware path scheme.
> >>> Includes cosmetic cleanups.
> >>>
> >>> Signed-off-by: David Heidelberg <david@...t.cz>
> >>> ---
> >>>   .../arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 23 +++++++++++
> >>> +++--------
> >>>   1 file changed, 15 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/
> >>> arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> >>> index db6dd04c51bb5..f1c63794db979 100644
> >>> --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> >>> @@ -181,8 +181,9 @@ panel_vddi_poc_1p8: panel-vddi-poc-regulator {
> >>>   };
> >>>     &adsp_pas {
> >>> +    firmware-name = "qcom/sdm845/OnePlus/enchilada/adsp.mbn";
> >>> +
> >>>       status = "okay";
> >>> -    firmware-name = "qcom/sdm845/oneplus6/adsp.mbn";
> >>>   };
> >>>     &apps_rsc {
> >>> @@ -353,8 +354,9 @@ vreg_s3c_0p6: smps3 {
> >>>   };
> >>>     &cdsp_pas {
> >>> +    firmware-name = "qcom/sdm845/OnePlus/enchilada/cdsp.mbn";
> >>> +
> >>>       status = "okay";
> >>> -    firmware-name = "qcom/sdm845/oneplus6/cdsp.mbn";
> >>>   };
> >>>     &gcc {
> >>> @@ -370,7 +372,7 @@ &gpu {
> >>>   };
> >>>     &gpu_zap_shader {
> >>> -    firmware-name = "qcom/sdm845/oneplus6/a630_zap.mbn";
> >>> +    firmware-name = "qcom/sdm845/OnePlus/enchilada/a630_zap.mbn";
> >>
> >> I believe this is considered as breaking backward compatibility. How
> >> about creating a symlink in linux-firmware instead.
> > 
> > See discussion here:
> > 
> > https://lore.kernel.org/linux-arm-msm/
> > CAO9ioeW9=TPde4P=AOcQANvPv90K-9MkcRRgb7HNwe8KiOpFjQ@...l.gmail.com/
> > 
> > I understood the conclusion was "let's do it".
> > 
> > We have more-less 3 consumers here,
> >  - postmarketOS (Alpine)
> >  - Mobian (Debian)
> >  - NixOS Mobile (NixOS)
> > 
> > some of these using droid-juicer, which can be easily updated to update
> > paths.
> > 
> 
> Dmitry,
> 
> How is this "not breaking backward compatibility"?

Indeed, it is a very gray zone. There is slight difference: firmware
loading can go through the userspace, which can provide backwards
compatibility (in form of fw helper, symlinks or any other ways).

So, yes, we break compatibility, but it is documented so and it can be
handled. Compare that with the e.g. updated driver rejecting old
bindings and thus becoming incompatible with the old DT.  This can't be
worked around in any way.


-- 
With best wishes
Dmitry