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

From: Dmitry Baryshkov
Date: Mon Apr 03 2023 - 08:55:02 EST


On Mon, 3 Apr 2023 at 15:46, Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
>
> On 03/04/2023 14:33, Krzysztof Kozlowski wrote:
> > 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@xxxxxxxxxx>
> >>>> ---
> >>>> 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@1300 {
> >>>> - 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)?
>
> 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.
>
> "Fixes" means that commit has a bug and this is how it should be fixed.
> So v6.0 kernel should be fixed to use "qcom,pmk8350-pon" compatible,
> which is obviously wrong. v6.0 does not support it and the "fix" would
> actually break it (which might be worse or better than original problem,
> but that's independent thing).

This patch fixes the issue in the commit ccd3517faf18. In the end, the
schema is describing the hardware, not just what the driver needs.
However, backporting this fix would also require one to cherry-pick
two other patches (one for the schema, one or two for the driver).

I think we should mention 0b65118e6ba3 ("Input: pm8941-pwrkey - add
software key press debouncing support") in the commit message (and
optionally 03fccdc76dce ("dt-bindings: power: reset: qcom-pon: Add new
compatible "qcom,pmk8350-pon"")). Using Cc:stable should probably be
left to patch authors (and I myself would not use them here).

--
With best wishes
Dmitry