arm64: dts: qcom: sc8280xp-pmics: fix pon compatible and registers
PATCH 1/1 arm64: dts: qcom: sc8280xp-pmics: fix pon compatible and registers
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).
--- arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +3 -2
@@ -59,8 +59,9 @@ pmk8280: pmic@0 { #size-cells = <0>; pmk8280_pon: pon@1300 { - compatible = "qcom,pm8998-pon"; - reg = <0x1300>; + compatible = "qcom,pmk8350-pon"; + reg = <0x1300>, <0x800>; + reg-names = "hlos", "pbs"; pmk8280_pon_pwrkey: pwrkey { compatible = "qcom,pmk8350-pwrkey";
Signature · 1 line
2.39.2
Quoted 8 lines · Johan Hovold
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_PBSaddress missing, can't read HW debounce time
Quoted 7 lines
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 <[email protected]>---
Konrad
Quoted 19 lines
arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +3
-2@@ -59,8 +59,9 @@ pmk8280: pmic@0 { #size-cells = <0>; pmk8280_pon: pon@1300 { - compatible = "qcom,pm8998-pon"; - reg = <0x1300>; + compatible = "qcom,pmk8350-pon"; + reg = <0x1300>, <0x800>; + reg-names = "hlos", "pbs"; pmk8280_pon_pwrkey: pwrkey { compatible = "qcom,pmk8350-pwrkey";
Quoted 36 lines · Johan Hovold
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_PBSaddress missing, can't read HW debounce timeNote 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 <[email protected]>--- arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +3
-3@@ -59,8 +59,9 @@ pmk8280: pmic@0 { #size-cells = <0>; pmk8280_pon: pon@1300 { - compatible = "qcom,pm8998-pon"; - reg = <0x1300>; + compatible = "qcom,pmk8350-pon"; + reg = <0x1300>, <0x800>; + reg-names = "hlos", "pbs"; pmk8280_pon_pwrkey: pwrkey { compatible = "qcom,pmk8350-pwrkey"; --
Quoted 2 lines
2.39.2
Tested on the Thinkpad X13s
Quoted 23 lines · Johan Hovold
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_PBSaddress missing, can't read HW debounce timeNote 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 <[email protected]>--- arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +0
-0
arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi pmk8280: pmic@0 { · line 62
Quoted 6 lines
arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +1
-2@@ -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.
Best regards,
Krzysztof
Quoted 35 lines · Krzysztof Kozlowski
Quoted 23 lines · Johan Hovold
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_PBSaddress missing, can't read HW debounce timeNote 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 <[email protected]>--- arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +0
-0arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi pmk8280: pmic@0 { · line 62
Quoted 6 lines
arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +1
-2@@ -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.
Quoted 1 line
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?
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.
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).
If 5.19-stable was still active and someone suggested backporting this 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.
Johan
Dmitry Baryshkov
Reviewed-byQuoted 37 lines · Johan Hovold
Quoted 35 lines · Krzysztof Kozlowski
Quoted 23 lines · Johan Hovold
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_PBSaddress missing, can't read HW debounce timeNote 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 <[email protected]>--- arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +0
-0arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi pmk8280: pmic@0 { · line 62
Quoted 6 lines
arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +1
-2@@ -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.
Quoted 3 lines
Quoted 1 line
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?
I'd tend to agree with Johan here. Neither of us has added the Cc:stable tags
Quoted 12 lines
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.
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).
If 5.19-stable was still active and someone suggested backporting this 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.
Signature · 2 lines
With best wishes Dmitry
Quoted 36 lines · Johan Hovold
Quoted 35 lines · Krzysztof Kozlowski
Quoted 23 lines · Johan Hovold
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_PBSaddress missing, can't read HW debounce timeNote 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 <[email protected]>--- arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +0
-0arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi pmk8280: pmic@0 { · line 62
Quoted 6 lines
arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +1
-2@@ -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.
Quoted 3 lines
Quoted 1 line
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.
Quoted 3 lines
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)?
Quoted 4 lines
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?
Quoted 2 lines
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!
Quoted 3 lines
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
Quoted 44 lines · Krzysztof Kozlowski
Quoted 36 lines · Johan Hovold
Quoted 35 lines · Krzysztof Kozlowski
Quoted 23 lines · Johan Hovold
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_PBSaddress missing, can't read HW debounce timeNote 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 <[email protected]>--- arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +0
-0arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi pmk8280: pmic@0 { · line 62
Quoted 6 lines
arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +1
-2@@ -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.Quoted 3 lines
Quoted 1 line
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.
Quoted 1 line
Quoted 6 lines
Quoted 2 lines
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).
Best regards,
Krzysztof
Quoted 58 lines · Krzysztof Kozlowski
Quoted 44 lines · Krzysztof Kozlowski
Quoted 36 lines · Johan Hovold
Quoted 35 lines · Krzysztof Kozlowski
Quoted 23 lines · Johan Hovold
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_PBSaddress missing, can't read HW debounce timeNote 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 <[email protected]>--- arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +0
-0arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi pmk8280: pmic@0 { · line 62
Quoted 6 lines
arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +1
-2@@ -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.Quoted 3 lines
Quoted 1 line
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.
Quoted 1 line
Quoted 6 lines
Quoted 2 lines
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.
Quoted 5 lines
"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).
Signature · 2 lines
With best wishes Dmitry
Quoted 6 lines · Krzysztof Kozlowski
Quoted 5 lines · Krzysztof Kozlowski
Quoted 2 lines · Johan Hovold
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.
Quoted 8 lines
Quoted 3 lines
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
Quoted 11 lines · Johan Hovold
Quoted 10 lines · Krzysztof Kozlowski
Quoted 8 lines · Krzysztof Kozlowski
Quoted 2 lines · Johan Hovold
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)?
Quoted 6 lines
Quoted 4 lines
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
Since this is your second mail in such tone and such phrases, I am not going to keep discussing this. Regardless of differences in opinion, you should keep the tone appropriate.
Best regards,
Krzysztof
Quoted 17 lines · Krzysztof Kozlowski
Quoted 16 lines · Johan Hovold
Quoted 14 lines · Krzysztof Kozlowski
Quoted 8 lines · Krzysztof Kozlowski
Quoted 2 lines · Johan Hovold
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.
Quoted 5 lines
Quoted 1 line
Now you're just making shit up. A fix is a fix for mainline, period. If
Since this is your second mail in such tone and such phrases, I am not going to keep discussing this. Regardless of differences in opinion, you should keep the tone appropriate.
Yeah, sorry about that. But please do consider how your own choice of words come across at times.
I agree that in the end it wasn't that clear cut as the state of the binding and driver was inconsistent in 5.19 (and 6.0), and if this had been an important fix that should be backported to trees where this mattered then that may have had to be taken into account.
Johan
Quoted 37 lines · Krzysztof Kozlowski
Quoted 36 lines · Johan Hovold
Quoted 35 lines · Krzysztof Kozlowski
Quoted 23 lines · Johan Hovold
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_PBSaddress missing, can't read HW debounce timeNote 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 <[email protected]>--- arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +0
-0arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi pmk8280: pmic@0 { · line 62
Quoted 6 lines
arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi +1
-2@@ -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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
6.0 stable is also EOL, and 6.1 has "qcom,pmk8350-pon".
Quoted 6 lines
Quoted 2 lines
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)?
The pwrkey started printing an error when the PON register was not defined in 5.18 so the problem was already there when support for sc8280xp was merged. Hence the Fixes tag.
0b65118e6ba3 ("Input: pm8941-pwrkey - add software key press debouncing support")
Quoted 8 lines
Quoted 3 lines
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?
You were the one who brought up AUTOSEL, but it's shortcomings should not be relevant here and that was my point.
No one is suggesting to backport this patch, but if someone were then they need to do just that and *port* it to 5.19 or whatever imaginary stable tree you care about which do not have "qcom,pmk8350-pon" (as I mentioned below).
Quoted 4 lines
Quoted 1 line
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!
That would be perfectly fine as, again, 6.1 has "qcom,pmk8350-pon".
Quoted 7 lines
Quoted 3 lines
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.
Exactly, and the same applies to fixes and arguable scripted backports as well.
Johan
Quoted 9 lines · Johan Hovold
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_PBSaddress missing, can't read HW debounce time[...]
Applied, thanks!
[1/1] arm64: dts: qcom: sc8280xp-pmics: fix pon compatible and registers
commit: ad8cd35c58ca3ec5e93f52a0124899627b98efb2
Best regards,
Signature · 1 line
Bjorn Andersson <[email protected]>