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]

Date:   Mon, 3 Apr 2023 14:33:01 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Johan Hovold <johan@...nel.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 03/04/2023 12:54, Johan Hovold wrote:
> On Mon, Apr 03, 2023 at 11:18:07AM +0200, Krzysztof Kozlowski wrote:
>> On 27/03/2023 14:29, Johan Hovold wrote:
>>> The pmk8280 PMIC PON peripheral is gen3 and uses two sets of registers;
>>> hlos and pbs.
>>>
>>> This specifically fixes the following error message during boot when the
>>> pbs registers are not defined:
>>>
>>> 	PON_PBS address missing, can't read HW debounce time
>>>
>>> Note that this also enables the spurious interrupt workaround introduced
>>> by commit 0b65118e6ba3 ("Input: pm8941-pwrkey - add software key press
>>> debouncing support") (which may or may not be needed).
>>>
>>> Fixes: ccd3517faf18 ("arm64: dts: qcom: sc8280xp: Add reference device")
>>> Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
>>> ---
>>>  arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi
>>> index c35e7f6bd657..a0ba535bb6c9 100644
>>> --- a/arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi
>>> @@ -59,8 +59,9 @@ pmk8280: pmic@0 {
>>>  		#size-cells = <0>;
>>>  
>>>  		pmk8280_pon: pon@...0 {
>>> -			compatible = "qcom,pm8998-pon";
>>> -			reg = <0x1300>;
>>> +			compatible = "qcom,pmk8350-pon";
>>
>> Same comment as Dmitry's. There is no compatible "qcom,pmk8350-pon"
>> ccd3517faf18, therefore indicated backport (through AUTOSEL) will lead
>> to invalid stable kernel.
>>
>> You must drop the Fixes tag, because this cannot be backported.
> 
> That's bullshit. Do you see a stable tag? Is 5.19-stable still active?

Why do you refer to activeness of v5.19? This will go also to v6.0 and v6.1.

> 
> 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)?

> 
> AUTOSEL is crazy and people apparently just ignore it instead of NAKing
> when it is suggesting backporting devicetree cleanups (which to be fair
> should generally not have Fixes tags in the first place).

Sorry, no clue what do you want to say here... if you are unhappy with
AUTOSEL, I am not the one to receive such feedback. Anyway, regardless
of AUTOSEL, my concern was that the release containing that commit was
not ready to work with that compatible. Isn't this the case here?

> 
> If 5.19-stable was still active and someone suggested backporting this

Whether v5.19 is active or not, it does not matter. Why would it matter?
This will go longterm v6.1 as well!

> one, they would have to change the compatible string to match the
> inconsistent 5.19 kernel. Note that that would need to happen regardless
> of whether this patch has a Fixes tag or not.

Any manual backporting of something which is not a fix for older kernel
is already risky business and whoever is doing it, he is responsible for
the outcome.

Best regards,
Krzysztof