[PATCH AUTOSEL 6.5 05/36] arm64: dts: qcom: sm6125-pdx201: correct ramoops pmsg-size

[PATCH AUTOSEL 6.5 05/36] arm64: dts: qcom: sm6125-pdx201: correct ramoops pmsg-size

[Sasha Levin]

From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

[ Upstream commit c42f5452de6ad2599c6e5e2a64c180a4ac835d27 ]

There is no 'msg-size' property in ramoops, so assume intention was for
'pmsg-size':

  sm6125-sony-xperia-seine-pdx201.dtb: ramoops@ffc00000: Unevaluated properties are not allowed ('msg-size' was unexpected)

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230618114442.140185-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts b/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts
index 9f8a9ef398a26..de85086c65adc 100644
--- a/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts
+++ b/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts
@@ -79,7 +79,7 @@ pstore_mem: ramoops@ffc00000 {
 			reg = <0x0 0xffc40000 0x0 0xc0000>;
 			record-size = <0x1000>;
 			console-size = <0x40000>;
-			msg-size = <0x20000 0x20000>;
+			pmsg-size = <0x20000>;
 		};
 
 		cmdline_mem: memory@ffd00000 {
-- 
2.40.1

[PATCH AUTOSEL 6.5 06/36] arm64: dts: qcom: sm6125-sprout: correct ramoops pmsg-size

[Sasha Levin]

From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

[ Upstream commit 2951e7e7611a3ea04de98d0f1bfc4e7ec609ef29 ]

There is no 'msg-size' property in ramoops, so assume intention was for
'pmsg-size':

  sm6125-xiaomi-laurel-sprout.dtb: ramoops@ffc00000: Unevaluated properties are not allowed ('msg-size' was unexpected)

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230618114442.140185-4-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
index a7f4aeae9c1a5..7c58d1299a609 100644
--- a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
+++ b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
@@ -52,7 +52,7 @@ pstore_mem: ramoops@ffc00000 {
 			reg = <0x0 0xffc40000 0x0 0xc0000>;
 			record-size = <0x1000>;
 			console-size = <0x40000>;
-			msg-size = <0x20000 0x20000>;
+			pmsg-size = <0x20000>;
 		};
 
 		cmdline_mem: memory@ffd00000 {
-- 
2.40.1

[PATCH AUTOSEL 6.5 07/36] arm64: dts: qcom: sm6350: correct ramoops pmsg-size

[Sasha Levin]

From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

[ Upstream commit c86b97a72065e06eacb993dc71fa9febc93422af ]

There is no 'msg-size' property in ramoops, so assume intention was for
'pmsg-size':

  sm6350-sony-xperia-lena-pdx213.dtb: ramoops@ffc00000: Unevaluated properties are not allowed ('msg-size' was unexpected)

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230618114442.140185-5-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index 30e77010aed57..698171bda9fa3 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -673,7 +673,7 @@ ramoops: ramoops@ffc00000 {
 			reg = <0 0xffc00000 0 0x100000>;
 			record-size = <0x1000>;
 			console-size = <0x40000>;
-			msg-size = <0x20000 0x20000>;
+			pmsg-size = <0x20000>;
 			ecc-size = <16>;
 			no-map;
 		};
-- 
2.40.1

[PATCH AUTOSEL 6.5 08/36] arm64: dts: qcom: sm8150-kumano: correct ramoops pmsg-size

[Sasha Levin]

From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

[ Upstream commit 4e6b942f092653ebcdbbc0819b2d1f08ab415bdc ]

There is no 'msg-size' property in ramoops, so assume intention was for
'pmsg-size':

  sm8150-sony-xperia-kumano-griffin.dtb: ramoops@ffc00000: Unevaluated properties are not allowed ('msg-size' was unexpected)

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230618114442.140185-6-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano.dtsi b/arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano.dtsi
index baafea53770bf..ae0ca48b89a59 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano.dtsi
@@ -222,7 +222,7 @@ ramoops@ffc00000 {
 			reg = <0x0 0xffc00000 0x0 0x100000>;
 			record-size = <0x1000>;
 			console-size = <0x40000>;
-			msg-size = <0x20000 0x20000>;
+			pmsg-size = <0x20000>;
 			ecc-size = <16>;
 			no-map;
 		};
-- 
2.40.1

[PATCH AUTOSEL 6.5 09/36] arm64: dts: qcom: sm8250-edo: correct ramoops pmsg-size

[Sasha Levin]

From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

[ Upstream commit 7dc3606f91427414d00a2fb09e6e0e32c14c2093 ]

There is no 'msg-size' property in ramoops, so assume intention was for
'pmsg-size':

  sm8250-sony-xperia-edo-pdx206.dtb: ramoops@ffc00000: Unevaluated properties are not allowed ('msg-size' was unexpected)

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230618114442.140185-7-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi b/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi
index 8ab82bacba81f..9f3ea8d8d7989 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi
@@ -112,7 +112,7 @@ ramoops@ffc00000 {
 			reg = <0x0 0xffc00000 0x0 0x100000>;
 			record-size = <0x1000>;
 			console-size = <0x40000>;
-			msg-size = <0x20000 0x20000>;
+			pmsg-size = <0x20000>;
 			ecc-size = <16>;
 			no-map;
 		};
-- 
2.40.1

[PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Sasha Levin]

From: Konrad Dybcio <konrad.dybcio@linaro.org>

[ Upstream commit 1c63dd1c5fdafa8854526d7d60d2b741c813678d ]

Disappointigly, the camera activity LED is implemented in software.
Hook it up as a gpio-led and (until we have camera *and* a "camera on"
LED trigger) configure it as a panic indicator.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230805-topic-x13s_cam_led-v1-1-443d752158c4@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts   | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index 7cc3028440b64..92f1d6d13435c 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -12,6 +12,7 @@
 #include <dt-bindings/iio/qcom,spmi-adc7-pmr735a.h>
 #include <dt-bindings/input/gpio-keys.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
 #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
 
 #include "sc8280xp.dtsi"
@@ -78,6 +79,21 @@ switch-lid {
 		};
 	};
 
+	leds {
+		compatible = "gpio-leds";
+
+		led-camera-indicator {
+			label = "white:camera-indicator";
+			function = LED_FUNCTION_INDICATOR;
+			color = <LED_COLOR_ID_WHITE>;
+			gpios = <&tlmm 28 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "none";
+			default-state = "off";
+			/* Reuse as a panic indicator until we get a "camera on" trigger */
+			panic-indicator;
+		};
+	};
+
 	pmic-glink {
 		compatible = "qcom,sc8280xp-pmic-glink", "qcom,pmic-glink";
 
-- 
2.40.1

Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Johan Hovold]

On Fri, Sep 08, 2023 at 03:28:41PM -0400, Sasha Levin wrote:
> From: Konrad Dybcio <konrad.dybcio@linaro.org>
> 
> [ Upstream commit 1c63dd1c5fdafa8854526d7d60d2b741c813678d ]
> 
> Disappointigly, the camera activity LED is implemented in software.
> Hook it up as a gpio-led and (until we have camera *and* a "camera on"
> LED trigger) configure it as a panic indicator.
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> Link: https://lore.kernel.org/r/20230805-topic-x13s_cam_led-v1-1-443d752158c4@linaro.org
> Signed-off-by: Bjorn Andersson <andersson@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

This is a new feature if anything, not a fix. Please drop from all
autosel queues.

Johan

Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Sasha Levin]

On Mon, Sep 11, 2023 at 08:33:02AM +0200, Johan Hovold wrote:
>On Fri, Sep 08, 2023 at 03:28:41PM -0400, Sasha Levin wrote:
>> From: Konrad Dybcio <konrad.dybcio@linaro.org>
>>
>> [ Upstream commit 1c63dd1c5fdafa8854526d7d60d2b741c813678d ]
>>
>> Disappointigly, the camera activity LED is implemented in software.
>> Hook it up as a gpio-led and (until we have camera *and* a "camera on"
>> LED trigger) configure it as a panic indicator.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> Link: https://lore.kernel.org/r/20230805-topic-x13s_cam_led-v1-1-443d752158c4@linaro.org
>> Signed-off-by: Bjorn Andersson <andersson@kernel.org>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>This is a new feature if anything, not a fix. Please drop from all
>autosel queues.

Not a feature, but hardware enablement.

-- 
Thanks,
Sasha

Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Johan Hovold]

On Mon, Sep 18, 2023 at 05:41:38PM -0400, Sasha Levin wrote:
> On Mon, Sep 11, 2023 at 08:33:02AM +0200, Johan Hovold wrote:
> >On Fri, Sep 08, 2023 at 03:28:41PM -0400, Sasha Levin wrote:
> >> From: Konrad Dybcio <konrad.dybcio@linaro.org>
> >>
> >> [ Upstream commit 1c63dd1c5fdafa8854526d7d60d2b741c813678d ]
> >>
> >> Disappointigly, the camera activity LED is implemented in software.
> >> Hook it up as a gpio-led and (until we have camera *and* a "camera on"
> >> LED trigger) configure it as a panic indicator.
> >>
> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> >> Link: https://lore.kernel.org/r/20230805-topic-x13s_cam_led-v1-1-443d752158c4@linaro.org
> >> Signed-off-by: Bjorn Andersson <andersson@kernel.org>
> >> Signed-off-by: Sasha Levin <sashal@kernel.org>
> >
> >This is a new feature if anything, not a fix. Please drop from all
> >autosel queues.
> 
> Not a feature, but hardware enablement.

Call it what you will, but please drop it. Otherwise by that logic you'd
need to backport all devicetree patches (as well as most driver changes)
since they ultimately aim at enabling hardware.

Johan

Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Sasha Levin]

On Tue, Sep 19, 2023 at 08:15:04AM +0200, Johan Hovold wrote:
>On Mon, Sep 18, 2023 at 05:41:38PM -0400, Sasha Levin wrote:
>> On Mon, Sep 11, 2023 at 08:33:02AM +0200, Johan Hovold wrote:
>> >On Fri, Sep 08, 2023 at 03:28:41PM -0400, Sasha Levin wrote:
>> >> From: Konrad Dybcio <konrad.dybcio@linaro.org>
>> >>
>> >> [ Upstream commit 1c63dd1c5fdafa8854526d7d60d2b741c813678d ]
>> >>
>> >> Disappointigly, the camera activity LED is implemented in software.
>> >> Hook it up as a gpio-led and (until we have camera *and* a "camera on"
>> >> LED trigger) configure it as a panic indicator.
>> >>
>> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> >> Link: https://lore.kernel.org/r/20230805-topic-x13s_cam_led-v1-1-443d752158c4@linaro.org
>> >> Signed-off-by: Bjorn Andersson <andersson@kernel.org>
>> >> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> >
>> >This is a new feature if anything, not a fix. Please drop from all
>> >autosel queues.
>>
>> Not a feature, but hardware enablement.
>
>Call it what you will, but please drop it. Otherwise by that logic you'd
>need to backport all devicetree patches (as well as most driver changes)
>since they ultimately aim at enabling hardware.

Not all, only ones that re-use existing kernel driver but enable it for
new hardware (i.e. adding a new pci-id/usb-id/dts entries).

-- 
Thanks,
Sasha

Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Johan Hovold]

On Tue, Sep 19, 2023 at 09:06:54AM -0400, Sasha Levin wrote:
> On Tue, Sep 19, 2023 at 08:15:04AM +0200, Johan Hovold wrote:
> >On Mon, Sep 18, 2023 at 05:41:38PM -0400, Sasha Levin wrote:
> >> On Mon, Sep 11, 2023 at 08:33:02AM +0200, Johan Hovold wrote:
> >> >On Fri, Sep 08, 2023 at 03:28:41PM -0400, Sasha Levin wrote:
> >> >> From: Konrad Dybcio <konrad.dybcio@linaro.org>
> >> >>
> >> >> [ Upstream commit 1c63dd1c5fdafa8854526d7d60d2b741c813678d ]
> >> >>
> >> >> Disappointigly, the camera activity LED is implemented in software.
> >> >> Hook it up as a gpio-led and (until we have camera *and* a "camera on"
> >> >> LED trigger) configure it as a panic indicator.
> >> >>
> >> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> >> >> Link: https://lore.kernel.org/r/20230805-topic-x13s_cam_led-v1-1-443d752158c4@linaro.org
> >> >> Signed-off-by: Bjorn Andersson <andersson@kernel.org>
> >> >> Signed-off-by: Sasha Levin <sashal@kernel.org>
> >> >
> >> >This is a new feature if anything, not a fix. Please drop from all
> >> >autosel queues.
> >>
> >> Not a feature, but hardware enablement.
> >
> >Call it what you will, but please drop it. Otherwise by that logic you'd
> >need to backport all devicetree patches (as well as most driver changes)
> >since they ultimately aim at enabling hardware.
> 
> Not all, only ones that re-use existing kernel driver but enable it for
> new hardware (i.e. adding a new pci-id/usb-id/dts entries).

Again, that's basically all our device-tree patches. And that can break
in all sorts of ways. So again, please drop. This does not belong in
stable.

Johan

Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Sasha Levin]

On Tue, Sep 19, 2023 at 03:28:24PM +0200, Johan Hovold wrote:
>On Tue, Sep 19, 2023 at 09:06:54AM -0400, Sasha Levin wrote:
>> On Tue, Sep 19, 2023 at 08:15:04AM +0200, Johan Hovold wrote:
>> >On Mon, Sep 18, 2023 at 05:41:38PM -0400, Sasha Levin wrote:
>> >> On Mon, Sep 11, 2023 at 08:33:02AM +0200, Johan Hovold wrote:
>> >> >On Fri, Sep 08, 2023 at 03:28:41PM -0400, Sasha Levin wrote:
>> >> >> From: Konrad Dybcio <konrad.dybcio@linaro.org>
>> >> >>
>> >> >> [ Upstream commit 1c63dd1c5fdafa8854526d7d60d2b741c813678d ]
>> >> >>
>> >> >> Disappointigly, the camera activity LED is implemented in software.
>> >> >> Hook it up as a gpio-led and (until we have camera *and* a "camera on"
>> >> >> LED trigger) configure it as a panic indicator.
>> >> >>
>> >> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> >> >> Link: https://lore.kernel.org/r/20230805-topic-x13s_cam_led-v1-1-443d752158c4@linaro.org
>> >> >> Signed-off-by: Bjorn Andersson <andersson@kernel.org>
>> >> >> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> >> >
>> >> >This is a new feature if anything, not a fix. Please drop from all
>> >> >autosel queues.
>> >>
>> >> Not a feature, but hardware enablement.
>> >
>> >Call it what you will, but please drop it. Otherwise by that logic you'd
>> >need to backport all devicetree patches (as well as most driver changes)
>> >since they ultimately aim at enabling hardware.
>>
>> Not all, only ones that re-use existing kernel driver but enable it for
>> new hardware (i.e. adding a new pci-id/usb-id/dts entries).
>
>Again, that's basically all our device-tree patches. And that can break
>in all sorts of ways. So again, please drop. This does not belong in
>stable.

This is part of the criteria we use to select patches, yes? If you have
an objection around this particular patch then please let me know, or if
you have an objection around hardware enablement patches in stable then
we can have a bigger discussion around that one.

However, just dropping this one for no particular reasonisn't the right
approach: we've been using this selection criteria for quite a few years
now.

-- 
Thanks,
Sasha

Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Johan Hovold]

On Tue, Sep 19, 2023 at 11:09:54AM -0400, Sasha Levin wrote:
> On Tue, Sep 19, 2023 at 03:28:24PM +0200, Johan Hovold wrote:
> >On Tue, Sep 19, 2023 at 09:06:54AM -0400, Sasha Levin wrote:
> >> On Tue, Sep 19, 2023 at 08:15:04AM +0200, Johan Hovold wrote:

> >> >Call it what you will, but please drop it. Otherwise by that logic you'd
> >> >need to backport all devicetree patches (as well as most driver changes)
> >> >since they ultimately aim at enabling hardware.
> >>
> >> Not all, only ones that re-use existing kernel driver but enable it for
> >> new hardware (i.e. adding a new pci-id/usb-id/dts entries).
> >
> >Again, that's basically all our device-tree patches. And that can break
> >in all sorts of ways. So again, please drop. This does not belong in
> >stable.
> 
> This is part of the criteria we use to select patches, yes? If you have
> an objection around this particular patch then please let me know, or if
> you have an objection around hardware enablement patches in stable then
> we can have a bigger discussion around that one.
> 
> However, just dropping this one for no particular reasonisn't the right
> approach: we've been using this selection criteria for quite a few years
> now.

This patch makes zero sense to backport. It's a place holder for a
camera led that we may one day need. No one marked it for stable, no
one wants it in stable, no one needs it in stable, yet you repeatedly
refuse to drop it and keep wasting my time.

Backports, and especially your autosel ones, always come with a risk.
And here there is ZERO upsides to that. Next time the feature you try to
retroactively enable may not be as trivial and could cause real
regressions.

We're on our knees dealing with development and review of stuff that
people do want and need. And you keep pushing silly things like and
spamming us with backports that no one asked for. I'm just baffled.

Johan

Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Johan Hovold]

On Tue, Sep 19, 2023 at 05:40:18PM +0200, Johan Hovold wrote:
> On Tue, Sep 19, 2023 at 11:09:54AM -0400, Sasha Levin wrote:
> > On Tue, Sep 19, 2023 at 03:28:24PM +0200, Johan Hovold wrote:
> > >On Tue, Sep 19, 2023 at 09:06:54AM -0400, Sasha Levin wrote:
> > >> On Tue, Sep 19, 2023 at 08:15:04AM +0200, Johan Hovold wrote:
> 
> > >> >Call it what you will, but please drop it. Otherwise by that logic you'd
> > >> >need to backport all devicetree patches (as well as most driver changes)
> > >> >since they ultimately aim at enabling hardware.
> > >>
> > >> Not all, only ones that re-use existing kernel driver but enable it for
> > >> new hardware (i.e. adding a new pci-id/usb-id/dts entries).
> > >
> > >Again, that's basically all our device-tree patches. And that can break
> > >in all sorts of ways. So again, please drop. This does not belong in
> > >stable.
> > 
> > This is part of the criteria we use to select patches, yes? If you have
> > an objection around this particular patch then please let me know, or if
> > you have an objection around hardware enablement patches in stable then
> > we can have a bigger discussion around that one.
> > 
> > However, just dropping this one for no particular reasonisn't the right
> > approach: we've been using this selection criteria for quite a few years
> > now.
> 
> This patch makes zero sense to backport. It's a place holder for a
> camera led that we may one day need. No one marked it for stable, no
> one wants it in stable, no one needs it in stable, yet you repeatedly
> refuse to drop it and keep wasting my time.
> 
> Backports, and especially your autosel ones, always come with a risk.
> And here there is ZERO upsides to that. Next time the feature you try to
> retroactively enable may not be as trivial and could cause real
> regressions.
> 
> We're on our knees dealing with development and review of stuff that
> people do want and need. And you keep pushing silly things like and
> spamming us with backports that no one asked for. I'm just baffled.

You also seem to have made up new stable kernel rules as adding device
tree nodes clearly doesn't fit the description in
stable-kernel-rules.rst:

	It must either fix a real bug that bothers people or just add a
	device ID.

(This used to say "New device IDs and quirks are also accepted.")

Johan

Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Thorsten Leemhuis]

[/me saw this by chance]

On 19.09.23 18:00, Johan Hovold wrote:
> On Tue, Sep 19, 2023 at 05:40:18PM +0200, Johan Hovold wrote:
>> On Tue, Sep 19, 2023 at 11:09:54AM -0400, Sasha Levin wrote:
>>> On Tue, Sep 19, 2023 at 03:28:24PM +0200, Johan Hovold wrote:
>>>> On Tue, Sep 19, 2023 at 09:06:54AM -0400, Sasha Levin wrote:
>>>>> On Tue, Sep 19, 2023 at 08:15:04AM +0200, Johan Hovold wrote:
> 
> You also seem to have made up new stable kernel rules

No, it was me who changed the text, as I saw people struggling with it
and noticed that's partly due to problems in the text. But just like
with code changes there's always a risk that slight changes to a text
result in unwanted effects. Not yet sure if that's the case here.

> as adding device
> tree nodes clearly doesn't fit the description in
> stable-kernel-rules.rst:
> 
> 	It must either fix a real bug that bothers people or just add a
> 	device ID.
> 
> (This used to say "New device IDs and quirks are also accepted.")

The "device IDs" part is still there (you quoted it); and a quirk is a
"real bug that bothers people", that's why it's mentioned a bit less
prominently now and just as a example (to quote a bit more from the
text: "It must either fix a real bug that bothers people or just add a
device ID. To elaborate on the former:

    It fixes a problem like an oops, a hang, data corruption, a real
security issue, a hardware quirk, [...]")

Make me wonder: why do you think "device tree nodes" were covered
before, but not anymore? What do you think should be changed to cover
them again?

Ciao, Thorsten

Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Johan Hovold]

On Wed, Sep 20, 2023 at 06:53:09AM +0200, Thorsten Leemhuis wrote:
> On 19.09.23 18:00, Johan Hovold wrote:
> > On Tue, Sep 19, 2023 at 05:40:18PM +0200, Johan Hovold wrote:

> > You also seem to have made up new stable kernel rules
> 
> No, it was me who changed the text, as I saw people struggling with it
> and noticed that's partly due to problems in the text. But just like
> with code changes there's always a risk that slight changes to a text
> result in unwanted effects. Not yet sure if that's the case here.

No, the updated text is just fine. My point was that Sasha's wish to
backport devicetree changes to enable hardware features violates the
stable kernel rules.

> > as adding device
> > tree nodes clearly doesn't fit the description in
> > stable-kernel-rules.rst:
> > 
> > 	It must either fix a real bug that bothers people or just add a
> > 	device ID.
> > 
> > (This used to say "New device IDs and quirks are also accepted.")

I just put the old formulation in parentheses for reference to avoid
having anyone think this was something new.

Johan

Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED

[Krzysztof Kozlowski]

On 19/09/2023 18:00, Johan Hovold wrote:
> On Tue, Sep 19, 2023 at 05:40:18PM +0200, Johan Hovold wrote:
>> On Tue, Sep 19, 2023 at 11:09:54AM -0400, Sasha Levin wrote:
>>> On Tue, Sep 19, 2023 at 03:28:24PM +0200, Johan Hovold wrote:
>>>> On Tue, Sep 19, 2023 at 09:06:54AM -0400, Sasha Levin wrote:
>>>>> On Tue, Sep 19, 2023 at 08:15:04AM +0200, Johan Hovold wrote:
>>
>>>>>> Call it what you will, but please drop it. Otherwise by that logic you'd
>>>>>> need to backport all devicetree patches (as well as most driver changes)
>>>>>> since they ultimately aim at enabling hardware.
>>>>>
>>>>> Not all, only ones that re-use existing kernel driver but enable it for
>>>>> new hardware (i.e. adding a new pci-id/usb-id/dts entries).
>>>>
>>>> Again, that's basically all our device-tree patches. And that can break
>>>> in all sorts of ways. So again, please drop. This does not belong in
>>>> stable.
>>>
>>> This is part of the criteria we use to select patches, yes? If you have
>>> an objection around this particular patch then please let me know, or if
>>> you have an objection around hardware enablement patches in stable then
>>> we can have a bigger discussion around that one.
>>>
>>> However, just dropping this one for no particular reasonisn't the right
>>> approach: we've been using this selection criteria for quite a few years
>>> now.
>>
>> This patch makes zero sense to backport. It's a place holder for a
>> camera led that we may one day need. No one marked it for stable, no
>> one wants it in stable, no one needs it in stable, yet you repeatedly
>> refuse to drop it and keep wasting my time.
>>
>> Backports, and especially your autosel ones, always come with a risk.
>> And here there is ZERO upsides to that. Next time the feature you try to
>> retroactively enable may not be as trivial and could cause real
>> regressions.
>>
>> We're on our knees dealing with development and review of stuff that
>> people do want and need. And you keep pushing silly things like and
>> spamming us with backports that no one asked for. I'm just baffled.
> 
> You also seem to have made up new stable kernel rules as adding device
> tree nodes clearly doesn't fit the description in
> stable-kernel-rules.rst:
> 
> 	It must either fix a real bug that bothers people or just add a
> 	device ID.
> 
> (This used to say "New device IDs and quirks are also accepted.")

I agree here with Johan. This is not a new device ID, not a quirk, not
minor stuff for hardware enablement. DTS describes the hardware for the
OS. The original commit is such new hardware description for previously
undescribed hardware. Such description might rely on changes in OS
drivers and might not work without driver patches, even if compatible
looks documented. Because this is not a quirk.

Such DTS patches should not be backported to stable kernels.

Best regards,
Krzysztof