linux-kernel - Re: [PATCH] arm64: dts: qcom: sc8280xp-pmics: fix pon compatible and registers

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]

Message-ID: <ZCrQe2ASeQXQJKS0@hovoldconsulting.com>
Date:   Mon, 3 Apr 2023 15:11:23 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Johan Hovold <johan+linaro@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: dts: qcom: sc8280xp-pmics: fix pon compatible and
 registers

On Mon, Apr 03, 2023 at 02:46:41PM +0200, Krzysztof Kozlowski wrote:
> On 03/04/2023 14:33, Krzysztof Kozlowski wrote:
> > On 03/04/2023 12:54, Johan Hovold wrote:

> >> The problem is that the driver was updated before the binding was so the
> >> above mentioned probe error has been there since this file was merged.
> > 
> > I grepped and that commit did not have such compatible. Are you saying
> > that the kernel which was released with this commit already had that
> > compatible in driver (through different merge/tree)?
> 
> So I double checked, the commit ccd3517faf18 (which is being "fixed")
> was introduced in v6.0-rc1. v6.0-rc1 did not have "qcom,pmk8350-pon"
> compatible, thus it could not be fixed that way. Therefore this cannot
> be logically fix for that commit from that release.

Now you're just making shit up. A fix is a fix for mainline, period. If
someone decides to backport a fix from mainline then that fix may need
to be adapted.

That said, sometimes some of us do take the state of previous versions
of the kernel into account when developing patches in order to
facilitate backports. That's a different thing and certainly not
something that is required to fix an issue in mainline.

Johan