[PATCH v3 00/12] Enable more nodes for the Xperia 10 III

[PATCH v3 00/12] Enable more nodes for the Xperia 10 III

[erebion]

Enable some more nodes for the Xperia 10 III.

Signed-off-by: erebion <erebion@erebion.eu>
---
Changes in v3:
- re-order some properties, generic properties first, then qcom,*
- &pm6150l_flash: fix led-max-microamp value
- rename touch-en-regulator to regulator-touch-en (to keep any future fixed-regulator sorted together as well)
- Bluetooth: remove incorrect property that does not exist
- Bluetooth, &qup_uart1_cts: do not overwrite a bias-disable with bias-bus-hold as it is not necessary
- &pm7250b_vbus: fix regulator-max-microamp value
- Remove comment from reserved-memory as suggested by Konrad Dybcio
- Squashed the patch enabling IPA into the one enabling ADSP, CDSP & MPSS, as suggested by Luca Weiss (therefore not adding the Reviewed-by from Konrad Dybcio)
- Configure thermals for PMK8350, PM7250B, PM650L as used in pdx213
- Enable remaining i2c busses
- Link to v2: https://patch.msgid.link/20260926-pdx213-upstream-3-v2-0-b4612e3eb536@erebion.eu

Changes in v2:
- Remove panel_reset_pin that shouldn't be part of this patch series
- Remove incorrect reg from mpss
- Fix conflicting bias pinctrl, as pinctrl nodes from sm6350.dtsi already contain a bias-* property
- Fix incorrect unit name in &pmk8350_vadc
- Link to v1: https://patch.msgid.link/20260926-pdx213-upstream-3-v1-0-1609c18b5c1d@erebion.eu

To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

---
erebion (12):
      arm64: dts: qcom: sm6350-lena: Add flash LED
      arm64: dts: qcom: sm6350-lena: rename touch-en-regulator
      arm64: dts: qcom: sm6350-lena: Add qcom,rmtfs-mem node
      arm64: dts: qcom: sm6350-lena: Enable ADSP, CDSP, IPA & MPSS
      arm64: dts: qcom: sm6350-lena: Enable Bluetooth
      arm64: dts: qcom: sm6350-lena: Enable wifi
      arm64: dts: qcom: sm6350-lena: Enable PM7250B
      arm64: dts: qcom: sm6350-lena: Enable PMK8350
      arm64: dts: qcom: sm6350-lena: Add PMK8350 thermals
      arm64: dts: qcom: sm6350-lena: Add PM7250B thermals
      arm64: dts: qcom: sm6350-lena: Add PM6150L thermals
      arm64: dts: qcom: sm6350-lena: enable remaining i2c busses

 .../dts/qcom/sm6350-sony-xperia-lena-pdx213.dts    | 503 ++++++++++++++++++++-
 1 file changed, 502 insertions(+), 1 deletion(-)
---
base-commit: e5e04726cdd043e309677071ab1b65a4b18f422b
change-id: 20260829-pdx213-upstream-3-d0b80f749b5b

Best regards,
--  
erebion <erebion@erebion.eu>

[PATCH v3 01/12] arm64: dts: qcom: sm6350-lena: Add flash LED

[erebion]

Add a node for the camera flash LED found on the Xperia 10 III

Reviewed-by: Luca Weiss <luca.weiss@fairphone.com>
Signed-off-by: erebion <erebion@erebion.eu>
---
 .../boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts      | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index 6e2bbf4f060ac..6942a117d41cf 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -4,9 +4,11 @@
  */
 /dts-v1/;
 
+#include <dt-bindings/leds/common.h>
 #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
 #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
 #include "sm6350.dtsi"
+#include "pm6150l.dtsi"
 #include "pm6350.dtsi"
 
 / {
@@ -302,6 +304,19 @@ touchscreen@48 {
 	};
 };
 
+&pm6150l_flash {
+	status = "okay";
+
+	led-0 {
+		function = LED_FUNCTION_FLASH;
+		color = <LED_COLOR_ID_WHITE>;
+		led-sources = <1>;
+		led-max-microamp = <1500000>;
+		flash-max-microamp = <1000000>;
+		flash-max-timeout-us = <1280000>;
+	};
+};
+
 &pm6350_gpios {
 	vol_down_n: vol-down-n-state {
 		pins = "gpio2";

-- 
2.53.0

Re: [PATCH v3 01/12] arm64: dts: qcom: sm6350-lena: Add flash LED

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: sm6350-lena: invalid led-max-microamp in pm6150l_flash
--

commit c063589d95e3f37ff34d230113ce64e10e062736
Author: erebion <erebion@erebion.eu>

arm64: dts: qcom: sm6350-lena: Add flash LED

This commit adds a devicetree node for the camera flash LED on the Sony
Xperia 10 III (pdx213).

> diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> index 6e2bbf4f060ac..6942a117d41cf 100644
> --- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts

[ ... ]

> @@ -302,6 +304,19 @@ touchscreen@48 {
>  	};
>  };
>  
> +&pm6150l_flash {
> +	status = "okay";
> +
> +	led-0 {
> +		function = LED_FUNCTION_FLASH;
> +		color = <LED_COLOR_ID_WHITE>;
> +		led-sources = <1>;
> +		led-max-microamp = <1500000>;
> +		flash-max-microamp = <1000000>;

[Severity: Medium]
Is led-max-microamp = <1500000> in pm6150l_flash intended here, or was a lower
continuous torch current limit such as 150000 uA meant instead?

In Documentation/devicetree/bindings/leds/common.yaml and
Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml,
led-max-microamp specifies the maximum continuous torch current, whereas
flash-max-microamp specifies the pulsed strobe flash current. The binding
schema constrains led-max-microamp to a maximum of 500000 uA for a single
channel (or 1000000 uA for two ganged channels):

Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml:
      led-max-microamp:
        anyOf:
          - minimum: 5000
            maximum: 500000
            multipleOf: 5000
          - minimum: 10000
            maximum: 1000000
            multipleOf: 10000

Setting led-max-microamp to 1500000 uA causes dtbs_check validation to fail
and sets the continuous torch limit higher than flash-max-microamp
(1000000 uA).

At runtime, when qcom_flash_led_probe() calls qcom_flash_register_led_device()
in drivers/leds/flash/leds-qcom-flash.c for a single-channel LED
(led-sources = <1>), the driver clamps led-max-microamp to the hardware per-
channel maximum of 500000 uA (TORCH_CURRENT_MAX_UA):

drivers/leds/flash/leds-qcom-flash.c:qcom_flash_register_led_device() {
	...
	current_ua = min_t(u32, current_ua, TORCH_CURRENT_MAX_UA * led->chan_count);
	led->max_torch_current_ma = current_ua / UA_PER_MA;
	...
}

This allows up to 500 mA in continuous torch mode rather than a board-specific
torch limit.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-pdx213-upstream-3-v3-0-cdc3be96d257@erebion.eu?part=1

Re: [PATCH v3 01/12] arm64: dts: qcom: sm6350-lena: Add flash LED

[erebion]

[-- Attachment #1.1: Type: text/plain, Size: 552 bytes --]

On 11/2/26 00:38, sashiko-bot@kernel.org wrote:
> [Severity: Medium]
> Is led-max-microamp = <1500000> in pm6150l_flash intended here, or was a lower
> continuous torch current limit such as 150000 uA meant instead?
Oh, that's a zero that should not be there and set the value 10x higher 
than it should be. Will fix in v4 of this patch series.

-- 
erebion

XMPP: erebion@erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the 
aforementioned languages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[PATCH v3 02/12] arm64: dts: qcom: sm6350-lena: rename touch-en-regulator

[erebion]

rename touch-en-regulator -> regulator-touch-en, to
keep any future fixed-regulator sorted together

Reviewed-by: Luca Weiss <luca.weiss@fairphone.com>
Signed-off-by: erebion <erebion@erebion.eu>
---
 arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index 6942a117d41cf..9295b2e6f179f 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -46,7 +46,16 @@ key-volume-down {
 		};
 	};
 
-	touch_en_vreg: touch-en-regulator {
+	lcdb_dummy: regulator-lcdb-dummy {
+		compatible = "regulator-fixed";
+		regulator-name = "lcdb_dummy";
+		regulator-min-microvolt = <5500000>;
+		regulator-max-microvolt = <5500000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	touch_en_vreg: regulator-touch-en {
 		compatible = "regulator-fixed";
 		regulator-name = "touch_en_vreg";
 		gpio = <&tlmm 10 GPIO_ACTIVE_HIGH>;

-- 
2.53.0

Re: [PATCH v3 02/12] arm64: dts: qcom: sm6350-lena: rename touch-en-regulator

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: sm6350-lena: stray unused regulator-lcdb-dummy node
- [Medium] arm64: dts: qcom: sm6350-lena: invalid led-max-microamp in pm6150l_flash
--

commit e7731bb19fd5c211a5eb8caeb5f7301cbd391239
Author: erebion <erebion@erebion.eu>

arm64: dts: qcom: sm6350-lena: rename touch-en-regulator

This commit renames touch-en-regulator to regulator-touch-en in
sm6350-sony-xperia-lena-pdx213.dts to keep fixed-regulator nodes sorted
together, and also adds a regulator-lcdb-dummy fixed-regulator node.

> diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> index 6942a117d41cf..9295b2e6f179f 100644
> --- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> @@ -46,7 +46,16 @@ key-volume-down {
>  		};
>  	};
>  
> -	touch_en_vreg: touch-en-regulator {
> +	lcdb_dummy: regulator-lcdb-dummy {
> +		compatible = "regulator-fixed";
> +		regulator-name = "lcdb_dummy";
> +		regulator-min-microvolt = <5500000>;
> +		regulator-max-microvolt = <5500000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};

[Severity: Medium]
Was regulator-lcdb-dummy included in this patch by mistake?

The commit message states that this change only renames touch-en-regulator to
regulator-touch-en, and nothing in sm6350-sony-xperia-lena-pdx213.dts or its
included dtsi files references the lcdb_dummy phandle, which results in an
unused always-on fixed regulator being registered at boot.

> +
> +	touch_en_vreg: regulator-touch-en {
>  		compatible = "regulator-fixed";
>  		regulator-name = "touch_en_vreg";
>  		gpio = <&tlmm 10 GPIO_ACTIVE_HIGH>;

[Severity: Medium]
Further down in arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts,
is led-max-microamp in the pm6150l_flash node configured with an out-of-range
value?

arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts:
&pm6150l_flash {
	status = "okay";

	led-0 {
		function = LED_FUNCTION_FLASH;
		color = <LED_COLOR_ID_WHITE>;
		led-sources = <1>;
		led-max-microamp = <1500000>;
		flash-max-microamp = <1000000>;
		flash-max-timeout-us = <1280000>;
	};
};

In Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml,
led-max-microamp specifies the maximum continuous torch current, which is
limited to 500000 uA for a single channel (or 1000000 uA across two ganged
channels):

      led-max-microamp:
        anyOf:
          - minimum: 5000
            maximum: 500000
            multipleOf: 5000
          - minimum: 10000
            maximum: 1000000
            multipleOf: 10000

Setting led-max-microamp to 1500000 uA on a single channel causes dtbs_check
validation to fail, configures the continuous torch current higher than
flash-max-microamp (1000000 uA), and causes qcom_flash_register_led_device()
in drivers/leds/flash/leds-qcom-flash.c to clamp the torch current to the
500000 uA PMIC channel limit:

	current_ua = min_t(u32, current_ua, TORCH_CURRENT_MAX_UA * led->chan_count);
	led->max_torch_current_ma = current_ua / UA_PER_MA;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-pdx213-upstream-3-v3-0-cdc3be96d257@erebion.eu?part=2

Re: [PATCH v3 02/12] arm64: dts: qcom: sm6350-lena: rename touch-en-regulator

[erebion]

[-- Attachment #1.1: Type: text/plain, Size: 672 bytes --]

On 11/2/26 00:38, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] arm64: dts: qcom: sm6350-lena: stray unused regulator-lcdb-dummy node

Oh no, that of course should not be in there and will remove that with 
v4 of this patch series...

> - [Medium] arm64: dts: qcom: sm6350-lena: invalid led-max-microamp in pm6150l_flash

Bot already complained on the flash LED patch...

-- 
erebion

XMPP: erebion@erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the 
aforementioned languages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH v3 02/12] arm64: dts: qcom: sm6350-lena: rename touch-en-regulator

[Konrad Dybcio]

On 11/2/26 12:32 AM, erebion wrote:
> rename touch-en-regulator -> regulator-touch-en, to
> keep any future fixed-regulator sorted together
> 
> Reviewed-by: Luca Weiss <luca.weiss@fairphone.com>
> Signed-off-by: erebion <erebion@erebion.eu>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

[PATCH v3 03/12] arm64: dts: qcom: sm6350-lena: Add qcom,rmtfs-mem node

[erebion]

Adds the qcom,rmtfs-mem node required for the modem

Reviewed-by: Luca Weiss <luca.weiss@fairphone.com>
Signed-off-by: erebion <erebion@erebion.eu>
---
 arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index 9295b2e6f179f..1e89c9798edf8 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -4,6 +4,7 @@
  */
 /dts-v1/;
 
+#include <dt-bindings/firmware/qcom,scm.h>
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
 #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
@@ -63,6 +64,17 @@ touch_en_vreg: regulator-touch-en {
 
 		vin-supply = <&pm6350_l6>;
 	};
+
+	reserved-memory {
+		memory@fe901000 {
+			compatible = "qcom,rmtfs-mem";
+			reg = <0x0 0xfe901000 0x0 0x280000>;
+			no-map;
+
+			qcom,client-id = <1>;
+			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
+		};
+	};
 };
 
 &apps_rsc {

-- 
2.53.0

Re: [PATCH v3 03/12] arm64: dts: qcom: sm6350-lena: Add qcom,rmtfs-mem node

[Konrad Dybcio]

On 11/2/26 12:32 AM, erebion wrote:
> Adds the qcom,rmtfs-mem node required for the modem
> 
> Reviewed-by: Luca Weiss <luca.weiss@fairphone.com>
> Signed-off-by: erebion <erebion@erebion.eu>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

[PATCH v3 04/12] arm64: dts: qcom: sm6350-lena: Enable ADSP, CDSP, IPA & MPSS

[erebion]

Enable the ADSP, CDSP, IPA and MPSS (Modem) nodes for the Xperia 10 III.

Reviewed-by: Luca Weiss <luca.weiss@fairphone.com>
Signed-off-by: erebion <erebion@erebion.eu>
---
 .../dts/qcom/sm6350-sony-xperia-lena-pdx213.dts    | 26 ++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index 1e89c9798edf8..ce351a3fa8727 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -77,6 +77,12 @@ memory@fe901000 {
 	};
 };
 
+&adsp {
+	firmware-name = "qcom/sm6350/sony/pdx213/adsp.mbn";
+
+	status = "okay";
+};
+
 &apps_rsc {
 	regulators-0 {
 		compatible = "qcom,pm6350-rpmh-regulators";
@@ -300,6 +306,12 @@ pm6150l_bob: bob {
 	};
 };
 
+&cdsp {
+	firmware-name = "qcom/sm6350/sony/pdx213/cdsp.mbn";
+
+	status = "okay";
+};
+
 &gpi_dma0 {
 	status = "okay";
 };
@@ -325,6 +337,20 @@ touchscreen@48 {
 	};
 };
 
+&ipa {
+	firmware-name = "qcom/sm6350/sony/pdx213/ipa_fws.mbn";
+	memory-region = <&pil_ipa_fw_mem>;
+	qcom,gsi-loader = "self";
+
+	status = "okay";
+};
+
+&mpss {
+	firmware-name = "qcom/sm6350/sony/pdx213/modem.mbn";
+
+	status = "okay";
+};
+
 &pm6150l_flash {
 	status = "okay";
 

-- 
2.53.0

Re: [PATCH v3 04/12] arm64: dts: qcom: sm6350-lena: Enable ADSP, CDSP, IPA & MPSS

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] arm64: dts: qcom: redundant IPA properties in sm6350-lena board DTS
--

commit ea5a49fe7f1eb96f27686737dd2b4c7bc009edc7
Author: erebion <erebion@erebion.eu>

arm64: dts: qcom: sm6350-lena: Enable ADSP, CDSP, IPA & MPSS

This commit enables the ADSP, CDSP, IPA, and MPSS nodes in the Device
Tree for the Sony Xperia 10 III (pdx213).

> diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> index 1e89c9798edf8..ce351a3fa8727 100644
> --- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts

[ ... ]

> @@ -325,6 +337,20 @@ touchscreen@48 {
>  	};
>  };
>  
> +&ipa {
> +	firmware-name = "qcom/sm6350/sony/pdx213/ipa_fws.mbn";
> +	memory-region = <&pil_ipa_fw_mem>;
> +	qcom,gsi-loader = "self";
> +
> +	status = "okay";
> +};

[Severity: Low]
Are memory-region and qcom,gsi-loader needed in &ipa here?

Commit dc88d56f27e0 ("arm64: dts: qcom: sm6350: consolidate IPA
properties") moved both properties into the base ipa: ipa@1e40000 node in
arch/arm64/boot/dts/qcom/sm6350.dtsi:

	ipa: ipa@1e40000 {
		compatible = "qcom,sm6350-ipa";
		...
		qcom,gsi-loader = "self";
		memory-region = <&pil_ipa_fw_mem>;
		status = "disabled";
	};

and dropped them from board files such as
arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts. Could &ipa in
arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts only specify
firmware-name and status = "okay", matching &adsp, &cdsp, and &mpss?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-pdx213-upstream-3-v3-0-cdc3be96d257@erebion.eu?part=4

Re: [PATCH v3 04/12] arm64: dts: qcom: sm6350-lena: Enable ADSP, CDSP, IPA & MPSS

[erebion]

[-- Attachment #1.1: Type: text/plain, Size: 474 bytes --]

On 11/2/26 00:41, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] arm64: dts: qcom: redundant IPA properties in sm6350-lena board DTS

Quite right, didn't notice that, fixed in v4...

-- 
erebion

XMPP: erebion@erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the 
aforementioned languages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH v3 04/12] arm64: dts: qcom: sm6350-lena: Enable ADSP, CDSP, IPA & MPSS

[Konrad Dybcio]

On 11/2/26 12:32 AM, erebion wrote:
> Enable the ADSP, CDSP, IPA and MPSS (Modem) nodes for the Xperia 10 III.
> 
> Reviewed-by: Luca Weiss <luca.weiss@fairphone.com>
> Signed-off-by: erebion <erebion@erebion.eu>
> ---
>  .../dts/qcom/sm6350-sony-xperia-lena-pdx213.dts    | 26 ++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> index 1e89c9798edf8..ce351a3fa8727 100644
> --- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> @@ -77,6 +77,12 @@ memory@fe901000 {
>  	};
>  };
>  
> +&adsp {
> +	firmware-name = "qcom/sm6350/sony/pdx213/adsp.mbn";

FWIW all other devices have an uppercase 'S' for Sony here, I'd
like to keep that consistent

Konrad

[PATCH v3 05/12] arm64: dts: qcom: sm6350-lena: Enable Bluetooth

[erebion]

Configure the required regulators for Bluetooth and enable it on the
Xperia 10 III.

Signed-off-by: erebion <erebion@erebion.eu>
---
 .../dts/qcom/sm6350-sony-xperia-lena-pdx213.dts    | 96 ++++++++++++++++++++++
 1 file changed, 96 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index ce351a3fa8727..f1958f4bad05a 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -19,6 +19,10 @@ / {
 	qcom,msm-id = <434 0x10000>, <459 0x10000>;
 	qcom,board-id = <0x1000b 0>;
 
+	aliases {
+		serial1 = &uart1;
+	};
+
 	chosen {
 		#address-cells = <2>;
 		#size-cells = <2>;
@@ -387,6 +391,32 @@ &qupv3_id_1 {
 	status = "okay";
 };
 
+/* UART1: HS UART for Bluetooth */
+&qup_uart1_rts {
+	/* We'll drive RTS, so no pull */
+	drive-strength = <2>;
+	/delete-property/ bias-pull-down;
+	bias-disable;
+};
+
+&qup_uart1_rx {
+	/*
+	 * Configure a pull-up on RX. This is needed to avoid
+	 * garbage data when the TX pin of the Bluetooth module is
+	 * in tri-state (module powered off or not driving the
+	 * signal yet).
+	 */
+	/delete-property/ bias-disable;
+	bias-pull-up;
+};
+
+&qup_uart1_tx {
+	/* We'll drive TX, so no pull */
+	drive-strength = <2>;
+	/delete-property/ bias-pull-up;
+	bias-disable;
+};
+
 &sdc2_off_state {
 	sd-cd-pins {
 		pins = "gpio94";
@@ -430,6 +460,72 @@ ts_int_default: ts-int-default-state {
 		drive-strength = <2>;
 		bias-disable;
 	};
+
+	qup_uart1_sleep_cts: qup-uart1-sleep-cts-state {
+		pins = "gpio61";
+		function = "gpio";
+		/*
+		 * Configure a bias-bus-hold on CTS to lower power
+		 * usage when Bluetooth is turned off. Bus hold will
+		 * maintain a low power state regardless of whether
+		 * the Bluetooth module drives the pin in either
+		 * direction or leaves the pin fully unpowered.
+		 */
+		bias-bus-hold;
+	};
+
+	qup_uart1_sleep_rts: qup-uart1-sleep-rts-state {
+		pins = "gpio62";
+		function = "gpio";
+		/*
+		 * Configure pull-down on RTS. As RTS is active low
+		 * signal, pull it low to indicate the BT SoC that it
+		 * can wakeup the system anytime from suspend state by
+		 * pulling RX low (by sending wakeup bytes).
+		 */
+		bias-pull-down;
+	};
+
+	qup_uart1_sleep_rx: qup-uart1-sleep-rx-state {
+		pins = "gpio64";
+		function = "gpio";
+		/*
+		 * Configure a pull-up on RX. This is needed to avoid
+		 * garbage data when the TX pin of the Bluetooth module
+		 * is floating which may cause spurious wakeups.
+		 */
+		bias-pull-up;
+	};
+
+	qup_uart1_sleep_tx: qup-uart1-sleep-tx-state {
+		pins = "gpio63";
+		function = "gpio";
+		/*
+		 * Configure pull-up on TX when it isn't actively driven
+		 * to prevent BT SoC from receiving garbage during sleep.
+		 */
+		bias-pull-up;
+	};
+};
+
+&uart1 {
+	/delete-property/ interrupts;
+	interrupts-extended = <&intc GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>,
+			     <&tlmm 64 IRQ_TYPE_EDGE_FALLING>;
+
+	pinctrl-names = "default", "sleep";
+	pinctrl-1 = <&qup_uart1_sleep_cts>, <&qup_uart1_sleep_rts>, <&qup_uart1_sleep_tx>, <&qup_uart1_sleep_rx>;
+
+	status = "okay";
+
+	bluetooth {
+		compatible = "qcom,wcn3991-bt";
+		vddio-supply = <&pm6350_l11>;
+		vddxo-supply = <&pm6350_l7>;
+		vddrf-supply = <&pm6150l_l2>;
+		vddch0-supply = <&pm6150l_l10>;
+		firmware-name = "crnv32u.bin";
+	};
 };
 
 &usb_1 {

-- 
2.53.0

Re: [PATCH v3 05/12] arm64: dts: qcom: sm6350-lena: Enable Bluetooth

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: missing bias-bus-hold on qup_uart1_cts in default state
--

commit c6c43a5057066bea59381415e228911af9075c62
Author: erebion <erebion@erebion.eu>

arm64: dts: qcom: sm6350-lena: Enable Bluetooth

This commit configures the UART1 pinmux, sleep states, and regulators to
enable the WCN3991 Bluetooth controller on the Sony Xperia 10 III.

> diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> index ce351a3fa8727..f1958f4bad05a 100644
> --- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
[ ... ]
> @@ -387,6 +391,32 @@ &qupv3_id_1 {
>  	status = "okay";
>  };
>  
> +/* UART1: HS UART for Bluetooth */
> +&qup_uart1_rts {
> +	/* We'll drive RTS, so no pull */
> +	drive-strength = <2>;
> +	/delete-property/ bias-pull-down;
> +	bias-disable;
> +};

[Severity: Medium]
Should this also override qup_uart1_cts to replace bias-disable with
bias-bus-hold in the default state, similar to qup_uart1_sleep_cts below
(and sm7225-fairphone-fp4.dts)?

In arch/arm64/boot/dts/qcom/sm6350.dtsi, qup_uart1_cts configures gpio61
with bias-disable:

	qup_uart1_cts: qup-uart1-cts-default-state {
		pins = "gpio61";
		function = "qup01";
		drive-strength = <2>;
		bias-disable;
	};

Because qca_serdev_probe() -> hci_uart_register_device_priv() ->
serdev_device_open() opens the UART port at probe time and keeps it open
even when Bluetooth is powered off via qca_hci_shutdown() ->
qca_power_off(), qcom_geni_serial_startup() holds an active runtime PM
reference on uart1 whenever the system is awake.

As a result, uart1 only switches to the sleep pinctrl state during
system-wide suspend in qcom_geni_serial_suspend() ->
pm_runtime_force_suspend(). When Bluetooth is turned off while the system
is awake, uart1 stays in the default pinctrl state, leaving gpio61 with
bias-disable instead of bias-bus-hold while the WCN3991 is unpowered.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-pdx213-upstream-3-v3-0-cdc3be96d257@erebion.eu?part=5

Re: [PATCH v3 05/12] arm64: dts: qcom: sm6350-lena: Enable Bluetooth

[erebion]

[-- Attachment #1.1: Type: text/plain, Size: 585 bytes --]

@ Konrad Dybcio: I removed it like you suggested, now the bot insists I 
add it back.

Hoping you can comment on the bot's disagreement with you. :)

On 11/2/26 00:45, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] arm64: dts: qcom: missing bias-bus-hold on qup_uart1_cts in default state
-- 
erebion

XMPP: erebion@erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the 
aforementioned languages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[PATCH v3 06/12] arm64: dts: qcom: sm6350-lena: Enable wifi

[erebion]

Configure regulators and enable it for the Xperia 10 III

Reviewed-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: erebion <erebion@erebion.eu>
---
 arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index f1958f4bad05a..1b54d9869855e 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -552,3 +552,13 @@ &usb_1_qmpphy {
 
 	status = "okay";
 };
+
+&wifi {
+	vdd-0.8-cx-mx-supply = <&pm6350_l4>;
+	vdd-1.8-xo-supply = <&pm6350_l7>;
+	vdd-1.3-rfa-supply = <&pm6150l_l2>;
+	vdd-3.3-ch0-supply = <&pm6150l_l10>;
+	vdd-3.3-ch1-supply = <&pm6150l_l11>;
+
+	status = "okay";
+};

-- 
2.53.0

[PATCH v3 07/12] arm64: dts: qcom: sm6350-lena: Enable PM7250B

[erebion]

Enable PM7250B and some components on it for the Xperia 10 III.

Signed-off-by: erebion <erebion@erebion.eu>
---
 .../dts/qcom/sm6350-sony-xperia-lena-pdx213.dts    | 48 ++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index 1b54d9869855e..61e191133cb4f 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -4,6 +4,10 @@
  */
 /dts-v1/;
 
+/* PM7250B is configured to use SID2/3 */
+#define PM7250B_SID 2
+#define PM7250B_SID1 3
+
 #include <dt-bindings/firmware/qcom,scm.h>
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
@@ -11,6 +15,7 @@
 #include "sm6350.dtsi"
 #include "pm6150l.dtsi"
 #include "pm6350.dtsi"
+#include "pm7250b.dtsi"
 
 / {
 	model = "Sony Xperia 10 III";
@@ -383,6 +388,49 @@ &pm6350_resin {
 	status = "okay";
 };
 
+&pm7250b_adc {
+	channel@4d {
+		reg = <ADC5_AMUX_THM1_100K_PU>;
+		label = "charger_skin_therm";
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+		qcom,ratiometric;
+	};
+
+	channel@4f {
+		reg = <ADC5_AMUX_THM3_100K_PU>;
+		label = "conn_therm";
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+		qcom,ratiometric;
+	};
+};
+
+&pm7250b_adc_tm {
+	status = "okay";
+
+	charger-skin-therm@0 {
+		reg = <0>;
+		io-channels = <&pm7250b_adc ADC5_AMUX_THM1_100K_PU>;
+		qcom,ratiometric;
+		qcom,hw-settle-time-us = <200>;
+	};
+
+	conn-therm@1 {
+		reg = <1>;
+		io-channels = <&pm7250b_adc ADC5_AMUX_THM3_100K_PU>;
+		qcom,ratiometric;
+		qcom,hw-settle-time-us = <200>;
+	};
+};
+
+&pm7250b_vbus {
+	regulator-min-microamp = <500000>;
+	regulator-max-microamp = <1000000>;
+
+	status = "okay";
+};
+
 &qupv3_id_0 {
 	status = "okay";
 };

-- 
2.53.0

Re: [PATCH v3 07/12] arm64: dts: qcom: sm6350-lena: Enable PM7250B

[Konrad Dybcio]

On 11/2/26 12:32 AM, erebion wrote:
> Enable PM7250B and some components on it for the Xperia 10 III.
> 
> Signed-off-by: erebion <erebion@erebion.eu>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

[PATCH v3 08/12] arm64: dts: qcom: sm6350-lena: Enable PMK8350

[erebion]

Configure and enable nodes for PMK8350 on the Xperia 10 III.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: erebion <erebion@erebion.eu>
---
 .../dts/qcom/sm6350-sony-xperia-lena-pdx213.dts    | 30 ++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index 61e191133cb4f..246a290e44f77 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -8,7 +8,11 @@
 #define PM7250B_SID 2
 #define PM7250B_SID1 3
 
+/* PMK8350 (in reality a PMK8003) is configured to use SID6 instead of 0 */
+#define PMK8350_SID 6
+
 #include <dt-bindings/firmware/qcom,scm.h>
+#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
 #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
@@ -16,6 +20,7 @@
 #include "pm6150l.dtsi"
 #include "pm6350.dtsi"
 #include "pm7250b.dtsi"
+#include "pmk8350.dtsi"
 
 / {
 	model = "Sony Xperia 10 III";
@@ -431,6 +436,31 @@ &pm7250b_vbus {
 	status = "okay";
 };
 
+&pmk8350_adc_tm {
+	status = "okay";
+
+	xo-therm@0 {
+		reg = <0>;
+		io-channels = <&pmk8350_vadc PMK8350_ADC7_AMUX_THM1_100K_PU>;
+		qcom,hw-settle-time-us = <200>;
+		qcom,ratiometric;
+	};
+};
+
+&pmk8350_rtc {
+	status = "okay";
+};
+
+&pmk8350_vadc {
+	channel@644 {
+		reg = <PMK8350_ADC7_AMUX_THM1_100K_PU>;
+		label = "xo_therm";
+		qcom,ratiometric;
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+	};
+};
+
 &qupv3_id_0 {
 	status = "okay";
 };

-- 
2.53.0

Re: [PATCH v3 08/12] arm64: dts: qcom: sm6350-lena: Enable PMK8350

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: sm6350-lena: duplicate qcom-pon device from pmk8350.dtsi
--

commit ab0852d01a0d63b999b8519d90b2ed3ef4a0420c
Author: erebion <erebion@erebion.eu>

arm64: dts: qcom: sm6350-lena: Enable PMK8350

This commit includes pmk8350.dtsi and configures and enables the PMK8350 ADC,
thermal monitor, and RTC nodes on the Sony Xperia 10 III.

> diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> index 61e191133cb4f..246a290e44f77 100644
> --- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> @@ -8,7 +8,11 @@
>  #define PM7250B_SID 2
>  #define PM7250B_SID1 3
>  
> +/* PMK8350 (in reality a PMK8003) is configured to use SID6 instead of 0 */
> +#define PMK8350_SID 6
> +
>  #include <dt-bindings/firmware/qcom,scm.h>
> +#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
>  #include <dt-bindings/leds/common.h>
>  #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
>  #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> @@ -16,6 +20,7 @@
>  #include "pm6150l.dtsi"
>  #include "pm6350.dtsi"
>  #include "pm7250b.dtsi"
> +#include "pmk8350.dtsi"

[Severity: Medium]
Does including pmk8350.dtsi alongside pm6350.dtsi without disabling or
deleting pmk8350_pon cause a probe conflict between two active qcom-pon
instances?

In arch/arm64/boot/dts/qcom/pm6350.dtsi, pm6350_pon is already enabled as the
primary PON device hosting reboot modes, pm6350_pwrkey, and pm6350_resin:

arch/arm64/boot/dts/qcom/pm6350.dtsi:
		pm6350_pon: pon@800 {
			compatible = "qcom,pm8998-pon";
			reg = <0x800>;
			mode-bootloader = <0x2>;
			mode-recovery = <0x1>;

In arch/arm64/boot/dts/qcom/pmk8350.dtsi, pmk8350_pon (and a root
/reboot-mode nvmem-reboot-mode node) is also enabled by default:

arch/arm64/boot/dts/qcom/pmk8350.dtsi:
		pmk8350_pon: pon@1300 {
			compatible = "qcom,pmk8350-pon";
			reg = <0x1300>, <0x800>;
			reg-names = "hlos", "pbs";

Both qcom,pm8998-pon and qcom,pmk8350-pon match qcom_pon_id_table with
reason_shift = GEN2_REASON_SHIFT in drivers/power/reset/qcom-pon.c:

qcom_pon_probe() {
	...
	if (reason_shift != NO_REASON_SHIFT) {
		pon->reboot_mode.dev = &pdev->dev;
		pon->reason_shift = reason_shift;
		pon->reboot_mode.write = qcom_pon_reboot_mode_write;
		error = devm_reboot_mode_register(&pdev->dev, &pon->reboot_mode);
		if (error) {
			dev_err(&pdev->dev, "can't register reboot mode\n");
			return error;
		}
	}

	platform_set_drvdata(pdev, pon);

	return devm_of_platform_populate(&pdev->dev);
}

In drivers/power/reset/reboot-mode.c, devm_reboot_mode_register() ->
reboot_mode_register() -> reboot_mode_create_device() registers a sysfs class
device named after reboot->dev->driver->name ("qcom-pon"):

reboot_mode_create_device() {
	...
	priv->reboot_mode_device = device_create(&reboot_mode_class, NULL, 0,
						 (void *)priv, "%s",
						 reboot->dev->driver->name);
	...
}

reboot_mode_register() {
	...
	ret = reboot_mode_create_device(reboot);
	if (ret)
		goto error;

	return 0;

error:
	kfree(info);
	reboot_mode_unregister(reboot);
	return ret;
}

When the second qcom-pon instance probes, device_create() fails with -EEXIST
and triggers a sysfs duplicate filename warning, and the error path in
reboot_mode_register() calls reboot_mode_unregister(), which looks up
"qcom-pon" by driver name via class_find_device(), unregisters the first
instance's sysfs device, and leaks the struct device reference returned by
class_find_device(). In addition, if pmk8350_pon probes before pm6350_pon,
qcom_pon_probe() for pm6350_pon returns an error before reaching
devm_of_platform_populate(), preventing pm6350_pwrkey and pm6350_resin from
being populated.

Should pmk8350_pon (and the root /reboot-mode node from pmk8350.dtsi) be
disabled or deleted in sm6350-sony-xperia-lena-pdx213.dts?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-pdx213-upstream-3-v3-0-cdc3be96d257@erebion.eu?part=8

Re: [PATCH v3 08/12] arm64: dts: qcom: sm6350-lena: Enable PMK8350

[erebion]

[-- Attachment #1.1: Type: text/plain, Size: 455 bytes --]

On 11/2/26 00:42, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] arm64: dts: qcom: sm6350-lena: duplicate qcom-pon device from pmk8350.dtsi

will disable in v4

-- 
erebion

XMPP: erebion@erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the 
aforementioned languages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[PATCH v3 09/12] arm64: dts: qcom: sm6350-lena: Add PMK8350 thermals

[erebion]

Configure the thermals for the xo-thermal thermistor connected to
PMK8350.

The trip points can really only be considered as placeholders, more
configuration with cooling etc. can be added later.

Signed-off-by: erebion <erebion@erebion.eu>
---
 .../arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index 246a290e44f77..6d5aa2fce4c0f 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -89,6 +89,20 @@ memory@fe901000 {
 			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
 		};
 	};
+
+	thermal-zones {
+		xo-thermal {
+			thermal-sensors = <&pmk8350_adc_tm 0>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "passive";
+				};
+			};
+		};
+	};
 };
 
 &adsp {

-- 
2.53.0

[PATCH v3 10/12] arm64: dts: qcom: sm6350-lena: Add PM7250B thermals

[erebion]

Configure the thermals for the chg-skin-thermal and conn-therm thermistors connected to
PM7250B.

The trip points can really only be considered as placeholders, more
configuration with cooling etc. can be added later.

Signed-off-by: erebion <erebion@erebion.eu>
---
 .../boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts    | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index 6d5aa2fce4c0f..4e9707712a651 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -91,8 +91,8 @@ memory@fe901000 {
 	};
 
 	thermal-zones {
-		xo-thermal {
-			thermal-sensors = <&pmk8350_adc_tm 0>;
+		chg-skin-thermal {
+			thermal-sensors = <&pm7250b_adc_tm 0>;
 
 			trips {
 				active-config0 {
@@ -102,6 +102,19 @@ active-config0 {
 				};
 			};
 		};
+
+		conn-thermal {
+			thermal-sensors = <&pm7250b_adc_tm 1>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "passive";
+				};
+			};
+		};
+
 	};
 };
 

-- 
2.53.0

Re: [PATCH v3 10/12] arm64: dts: qcom: sm6350-lena: Add PM7250B thermals

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: sm6350-lena: xo-thermal overwritten by chg-skin-thermal
--

commit f17bc49f693d9b82548c205964560df1771e0079
Author: erebion <erebion@erebion.eu>

arm64: dts: qcom: sm6350-lena: Add PM7250B thermals

This commit adds thermal zones for the chg-skin-thermal and conn-thermal
thermistors connected to PM7250B on Sony Xperia 10 III (pdx213).

> diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> index 6d5aa2fce4c0f..4e9707712a651 100644
> --- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> @@ -91,8 +91,8 @@ memory@fe901000 {
>  	};
>  
>  	thermal-zones {
> -		xo-thermal {
> -			thermal-sensors = <&pmk8350_adc_tm 0>;
> +		chg-skin-thermal {
> +			thermal-sensors = <&pm7250b_adc_tm 0>;

[Severity: Medium]
Was xo-thermal intentionally removed here?

In the preceding commits ("arm64: dts: qcom: sm6350-lena: Enable PMK8350"
and "arm64: dts: qcom: sm6350-lena: Add PMK8350 thermals"), pmk8350_adc_tm
is enabled with child node xo-therm@0:

&pmk8350_adc_tm {
	status = "okay";

	xo-therm@0 {
		reg = <0>;
		io-channels = <&pmk8350_vadc PMK8350_ADC7_AMUX_THM1_100K_PU>;
		qcom,hw-settle-time-us = <200>;
		qcom,ratiometric;
	};
};

and the xo-thermal zone referencing <&pmk8350_adc_tm 0> is added under
thermal-zones.

Here, chg-skin-thermal replaces xo-thermal in-place rather than being added
alongside it. When drivers/thermal/qcom/qcom-spmi-adc-tm5.c probes
pmk8350_adc_tm via adc_tm5_probe() -> adc_tm5_register_tzd() ->
devm_thermal_of_zone_register(), registering channel 0 fails with -ENODEV
because no thermal zone references <&pmk8350_adc_tm 0> at this commit.

It looks like a hunk-splitting error across the series, as the subsequent
commit ("arm64: dts: qcom: sm6350-lena: Add PM6150L thermals") re-adds the
deleted xo-thermal node at the end of thermal-zones. Should xo-thermal be
preserved in this commit instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-pdx213-upstream-3-v3-0-cdc3be96d257@erebion.eu?part=10

Re: [PATCH v3 10/12] arm64: dts: qcom: sm6350-lena: Add PM7250B thermals

[erebion]

[-- Attachment #1.1: Type: text/plain, Size: 486 bytes --]

Oy yes, the bot is right, rebase mishap, will fix...

On 11/2/26 00:44, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] arm64: dts: qcom: sm6350-lena: xo-thermal overwritten by chg-skin-thermal
-- 
erebion

XMPP: erebion@erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the 
aforementioned languages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[PATCH v3 11/12] arm64: dts: qcom: sm6350-lena: Add PM6150L thermals

[erebion]

Configure the thermals for the PA_THERM1, MSM_THERM, PA_THERM0,
RFC_CAM_THERM, CAM_FLASH_THERM and QUIET_THERM thermistors connected to
PM6150L.

Due to hardware constraints we can only register 4 zones with
pm6150l_adc_tm, the other 2 we can register via generic-adc-thermal.

The trip points can really only be considered as placeholders, more
configuration with cooling etc. can be added later.

Signed-off-by: erebion <erebion@erebion.eu>
---
 .../dts/qcom/sm6350-sony-xperia-lena-pdx213.dts    | 202 +++++++++++++++++++++
 1 file changed, 202 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index 4e9707712a651..487ef75f2f1de 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -12,7 +12,9 @@
 #define PMK8350_SID 6
 
 #include <dt-bindings/firmware/qcom,scm.h>
+#include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
+#include <dt-bindings/input/input.h>
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
 #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
@@ -70,6 +72,20 @@ lcdb_dummy: regulator-lcdb-dummy {
 		regulator-boot-on;
 	};
 
+	msm_therm_sensor: thermal-sensor-msm {
+		compatible = "generic-adc-thermal";
+		#thermal-sensor-cells = <0>;
+		io-channels = <&pm6150l_adc ADC5_AMUX_THM2_100K_PU>;
+		io-channel-names = "sensor-channel";
+	};
+
+	rear_cam_sensor: thermal-sensor-rear-cam {
+		compatible = "generic-adc-thermal";
+		#thermal-sensor-cells = <0>;
+		io-channels = <&pm6150l_adc ADC5_GPIO6_100K_PU>;
+		io-channel-names = "sensor-channel";
+	};
+
 	touch_en_vreg: regulator-touch-en {
 		compatible = "regulator-fixed";
 		regulator-name = "touch_en_vreg";
@@ -115,6 +131,99 @@ active-config0 {
 			};
 		};
 
+		pa0-thermal {
+			thermal-sensors = <&pm6150l_adc_tm 1>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "passive";
+				};
+			};
+		};
+
+		pa1-thermal {
+			thermal-sensors = <&pm6150l_adc_tm 0>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "passive";
+				};
+			};
+		};
+
+		quiet-thermal {
+			thermal-sensors = <&pm6150l_adc_tm 3>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "passive";
+				};
+			};
+		};
+
+		rear-cam-thermal {
+			polling-delay-passive = <1000>;
+			polling-delay = <5000>;
+			thermal-sensors = <&rear_cam_sensor>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "passive";
+				};
+			};
+		};
+
+		rfc-flash-thermal {
+			thermal-sensors = <&pm6150l_adc_tm 2>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "passive";
+				};
+			};
+		};
+
+		sdm-skin-thermal {
+			polling-delay-passive = <1000>;
+			polling-delay = <5000>;
+			thermal-sensors = <&msm_therm_sensor>;
+
+			trips {
+				trip0 {
+					temperature = <45000>;
+					hysteresis = <0>;
+					type = "passive";
+				};
+
+				trip1 {
+					temperature = <55000>;
+					hysteresis = <0>;
+					type = "critical";
+				};
+			};
+		};
+
+		xo-thermal {
+			thermal-sensors = <&pmk8350_adc_tm 0>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "passive";
+				};
+			};
+		};
 	};
 };
 
@@ -392,6 +501,99 @@ &mpss {
 	status = "okay";
 };
 
+&pm6150l_gpios {
+	pm6150l_adc_default: adc-default-state {
+		pins = "gpio6", "gpio7", "gpio10";
+		function = PMIC_GPIO_FUNC_NORMAL;
+		bias-high-impedance;
+	};
+};
+
+&pm6150l_adc {
+	pinctrl-0 = <&pm6150l_adc_default>;
+	pinctrl-names = "default";
+
+	channel@4d {
+		reg = <ADC5_AMUX_THM1_100K_PU>;
+		label = "pa_therm1";
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+		qcom,ratiometric;
+	};
+
+	channel@4e {
+		reg = <ADC5_AMUX_THM2_100K_PU>;
+		label = "msm_therm";
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+		qcom,ratiometric;
+	};
+
+	channel@4f {
+		reg = <ADC5_AMUX_THM3_100K_PU>;
+		label = "pa_therm0";
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+		qcom,ratiometric;
+	};
+
+	channel@53 {
+		reg = <ADC5_GPIO2_100K_PU>;
+		label = "rear_cam_therm";
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+		qcom,ratiometric;
+	};
+
+	channel@54 {
+		reg = <ADC5_GPIO3_100K_PU>;
+		label = "rear_cam_flash_therm";
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+		qcom,ratiometric;
+	};
+
+	channel@55 {
+		reg = <ADC5_GPIO4_100K_PU>;
+		label = "quiet_therm";
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+		qcom,ratiometric;
+	};
+};
+
+&pm6150l_adc_tm {
+	status = "okay";
+
+	pa-therm1@0 {
+		reg = <0>;
+		io-channels = <&pm6150l_adc ADC5_AMUX_THM1_100K_PU>;
+		qcom,hw-settle-time-us = <200>;
+		qcom,ratiometric;
+	};
+
+	pa-therm0@1 {
+		reg = <1>;
+		io-channels = <&pm6150l_adc ADC5_AMUX_THM3_100K_PU>;
+		qcom,hw-settle-time-us = <200>;
+		qcom,ratiometric;
+	};
+
+	rear-cam-flash-therm@2 {
+		reg = <2>;
+		io-channels = <&pm6150l_adc ADC5_GPIO3_100K_PU>;
+		qcom,hw-settle-time-us = <200>;
+		qcom,ratiometric;
+		};
+
+	quiet-therm@3 {
+		reg = <3>;
+		io-channels = <&pm6150l_adc ADC5_GPIO4_100K_PU>;
+		qcom,hw-settle-time-us = <200>;
+		qcom,ratiometric;
+	};
+};
+
 &pm6150l_flash {
 	status = "okay";
 

-- 
2.53.0

Re: [PATCH v3 11/12] arm64: dts: qcom: sm6350-lena: Add PM6150L thermals

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: wrong io-channels specifier on rear_cam_sensor
- [Low] arm64: dts: qcom: misplaced xo-thermal, unused includes, and style issues
--

commit ac86db420f5582034afb81e70777f975abaf47c9
Author: erebion <erebion@erebion.eu>

arm64: dts: qcom: sm6350-lena: Add PM6150L thermals

This commit adds ADC channels, ADC_TM channels, generic-adc-thermal sensors,
and thermal zones for the thermistors connected to PM6150L on the Sony Xperia
10 III (lena).

> diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> index 4e9707712a651..487ef75f2f1de 100644
> --- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> @@ -12,7 +12,9 @@
>  #define PMK8350_SID 6
>  
>  #include <dt-bindings/firmware/qcom,scm.h>
> +#include <dt-bindings/gpio/gpio.h>
>  #include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
> +#include <dt-bindings/input/input.h>
>  #include <dt-bindings/leds/common.h>
>  #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
>  #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> @@ -70,6 +72,20 @@ lcdb_dummy: regulator-lcdb-dummy {
>  		regulator-boot-on;
>  	};
>  
> +	msm_therm_sensor: thermal-sensor-msm {
> +		compatible = "generic-adc-thermal";
> +		#thermal-sensor-cells = <0>;
> +		io-channels = <&pm6150l_adc ADC5_AMUX_THM2_100K_PU>;
> +		io-channel-names = "sensor-channel";
> +	};
> +
> +	rear_cam_sensor: thermal-sensor-rear-cam {
> +		compatible = "generic-adc-thermal";
> +		#thermal-sensor-cells = <0>;
> +		io-channels = <&pm6150l_adc ADC5_GPIO6_100K_PU>;
> +		io-channel-names = "sensor-channel";
> +	};

[Severity: Medium]
Should rear_cam_sensor reference ADC5_GPIO2_100K_PU instead of
ADC5_GPIO6_100K_PU here?

On PM6150L, physical pin gpio6 is routed to ADC5_GPIO2_100K_PU (0x53), and
under &pm6150l_adc below the rear camera thermistor channel is defined as:

	channel@53 {
		reg = <ADC5_GPIO2_100K_PU>;
		label = "rear_cam_therm";

When gadc_thermal_probe() calls devm_iio_channel_get() for rear_cam_sensor,
adc5_fwnode_xlate() in drivers/iio/adc/qcom-spmi-adc5.c searches the channels
registered under &pm6150l_adc for a matching channel number:

	for (i = 0; i < adc->nchannels; i++)
		if (adc->chan_props[i].channel == iiospec->args[0])
			return i;

	return -EINVAL;

Because no channel is registered for ADC5_GPIO6_100K_PU (and adc5_chans_pmic[]
only defines 100K pull-up GPIO channels up to ADC5_GPIO4_100K_PU), probing
rear_cam_sensor fails with -EINVAL and leaves rear-cam-thermal non-functional.

[ ... ]

> @@ -115,6 +131,99 @@ active-config0 {

[ ... ]

> +		xo-thermal {
> +			thermal-sensors = <&pmk8350_adc_tm 0>;
> +
> +			trips {
> +				active-config0 {
> +					temperature = <125000>;
> +					hysteresis = <1000>;
> +					type = "passive";
> +				};
> +			};
> +		};
>  	};
>  };
>  
> @@ -392,6 +501,99 @@ &mpss {
>  	status = "okay";
>  };
>  
> +&pm6150l_gpios {
> +	pm6150l_adc_default: adc-default-state {
> +		pins = "gpio6", "gpio7", "gpio10";
> +		function = PMIC_GPIO_FUNC_NORMAL;
> +		bias-high-impedance;
> +	};
> +};
> +
> +&pm6150l_adc {

[ ... ]

> +&pm6150l_adc_tm {
> +	status = "okay";
> +
> +	pa-therm1@0 {
> +		reg = <0>;
> +		io-channels = <&pm6150l_adc ADC5_AMUX_THM1_100K_PU>;
> +		qcom,hw-settle-time-us = <200>;
> +		qcom,ratiometric;
> +	};
> +
> +	pa-therm0@1 {
> +		reg = <1>;
> +		io-channels = <&pm6150l_adc ADC5_AMUX_THM3_100K_PU>;
> +		qcom,hw-settle-time-us = <200>;
> +		qcom,ratiometric;
> +	};
> +
> +	rear-cam-flash-therm@2 {
> +		reg = <2>;
> +		io-channels = <&pm6150l_adc ADC5_GPIO3_100K_PU>;
> +		qcom,hw-settle-time-us = <200>;
> +		qcom,ratiometric;
> +		};

[Severity: Low]
This isn't a runtime bug, but there are a few patch split and style issues
across this change:

1. Earlier in the series, commit ff24120a08d6 ("arm64: dts: qcom: sm6350-lena:
Add PMK8350 thermals") added xo-thermal, and the next commit f17bc49f693d
("arm64: dts: qcom: sm6350-lena: Add PM7250B thermals") accidentally removed
it. Re-adding xo-thermal here puts a PMK8350 thermal zone into the PM6150L
thermal patch. Could xo-thermal be kept in the PMK8350 patch instead?

2. The newly added dt-bindings/gpio/gpio.h and dt-bindings/input/input.h
includes at the top of the file do not appear to be used by this patch.

3. Label references at the bottom of the file are sorted alphabetically, so
should &pm6150l_gpios be placed after &pm6150l_flash rather than before
&pm6150l_adc?

4. The closing brace of rear-cam-flash-therm@2 has an extra tab of
indentation.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-pdx213-upstream-3-v3-0-cdc3be96d257@erebion.eu?part=11

Re: [PATCH v3 11/12] arm64: dts: qcom: sm6350-lena: Add PM6150L thermals

[erebion]

[-- Attachment #1.1: Type: text/plain, Size: 1801 bytes --]

On 11/2/26 00:44, sashiko-bot@kernel.org wrote:
> [Severity: Medium]
> Should rear_cam_sensor reference ADC5_GPIO2_100K_PU instead of
> ADC5_GPIO6_100K_PU here?
> 
> On PM6150L, physical pin gpio6 is routed to ADC5_GPIO2_100K_PU (0x53), and
> under &pm6150l_adc below the rear camera thermistor channel is defined as:

Ah yes, looks like I confused gpio6 from downstream DT and gpio2 from 
include/dt-bindings/iio/qcom,spmi-vadc.h

Will fix with v4...

> [Severity: Low]
> This isn't a runtime bug, but there are a few patch split and style issues
> across this change:
> 
> 1. Earlier in the series, commit ff24120a08d6 ("arm64: dts: qcom: sm6350-lena:
> Add PMK8350 thermals") added xo-thermal, and the next commit f17bc49f693d
> ("arm64: dts: qcom: sm6350-lena: Add PM7250B thermals") accidentally removed
> it. Re-adding xo-thermal here puts a PMK8350 thermal zone into the PM6150L
> thermal patch. Could xo-thermal be kept in the PMK8350 patch instead?

The bot already commented this on the other patch... I know, rebase 
mishap, fixed...

> 2. The newly added dt-bindings/gpio/gpio.h and dt-bindings/input/input.h
> includes at the top of the file do not appear to be used by this patch.

Oh yes, will remove.

> 3. Label references at the bottom of the file are sorted alphabetically, so
> should &pm6150l_gpios be placed after &pm6150l_flash rather than before
> &pm6150l_adc?

Oh yes, will re-train the alphabet and fix that as well... :)

> 4. The closing brace of rear-cam-flash-therm@2 has an extra tab of
> indentation.
> 

also fixed in v4...

-- 
erebion

XMPP: erebion@erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the 
aforementioned languages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH v3 11/12] arm64: dts: qcom: sm6350-lena: Add PM6150L thermals

[erebion]

[-- Attachment #1.1: Type: text/plain, Size: 1201 bytes --]

On 11/2/26 01:35, erebion wrote:
> On 11/2/26 00:44, sashiko-bot@kernel.org wrote:
>> [Severity: Medium]
>> Should rear_cam_sensor reference ADC5_GPIO2_100K_PU instead of
>> ADC5_GPIO6_100K_PU here?
>>
>> On PM6150L, physical pin gpio6 is routed to ADC5_GPIO2_100K_PU (0x53), 
>> and
>> under &pm6150l_adc below the rear camera thermistor channel is defined 
>> as:
> 
> Ah yes, looks like I confused gpio6 from downstream DT and gpio2 from 
> include/dt-bindings/iio/qcom,spmi-vadc.h
> 
> Will fix with v4...
root@mobian:~# cat /sys/class/thermal/thermal_zone38/temp
-40000
root@mobian:~# cat /sys/class/thermal/thermal_zone38/type
rear-cam-thermal

Well, this does not look right either. I swear I don't live in Antarctica.


 >> Should rear_cam_sensor reference ADC5_GPIO2_100K_PU instead of
 >> ADC5_GPIO6_100K_PU here?

GPIO6: Value looks sensible at just over 30 °C
GPIO2: -40 °C

Perhaps GPIO6 was right after all or it is wrong while GPIO2 is wrong as 
well.

-- 
erebion

XMPP: erebion@erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the 
aforementioned languages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH v3 11/12] arm64: dts: qcom: sm6350-lena: Add PM6150L thermals

[erebion]

[-- Attachment #1.1: Type: text/plain, Size: 1417 bytes --]


On 11/2/26 02:33, erebion wrote:
> On 11/2/26 01:35, erebion wrote:
>> On 11/2/26 00:44, sashiko-bot@kernel.org wrote:
>>> [Severity: Medium]
>>> Should rear_cam_sensor reference ADC5_GPIO2_100K_PU instead of
>>> ADC5_GPIO6_100K_PU here?
>>>
>>> On PM6150L, physical pin gpio6 is routed to ADC5_GPIO2_100K_PU 
>>> (0x53), and
>>> under &pm6150l_adc below the rear camera thermistor channel is 
>>> defined as:
>>
>> Ah yes, looks like I confused gpio6 from downstream DT and gpio2 from 
>> include/dt-bindings/iio/qcom,spmi-vadc.h
>>
>> Will fix with v4...
> root@mobian:~# cat /sys/class/thermal/thermal_zone38/temp
> -40000
> root@mobian:~# cat /sys/class/thermal/thermal_zone38/type
> rear-cam-thermal
> 
> Well, this does not look right either. I swear I don't live in Antarctica.
> 
> 
>  >> Should rear_cam_sensor reference ADC5_GPIO2_100K_PU instead of
>  >> ADC5_GPIO6_100K_PU here?
> 
> GPIO6: Value looks sensible at just over 30 °C
> GPIO2: -40 °C
> 
> Perhaps GPIO6 was right after all or it is wrong while GPIO2 is wrong as 
> well.
> 

Oh yes. Now I get it...

I changed rear_cam_sensor to GPIO6, but left at set to GPIO2 in 
channel@53...

will fix with v4

-- 
erebion

XMPP: erebion@erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the 
aforementioned languages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[PATCH v3 12/12] arm64: dts: qcom: sm6350-lena: enable remaining i2c busses

[erebion]

Enable all i2c busses where something is connected on this phone. Add
comments as placeholders for which components are still missing.

Signed-off-by: erebion <erebion@erebion.eu>
---
 .../dts/qcom/sm6350-sony-xperia-lena-pdx213.dts    | 26 ++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
index 487ef75f2f1de..d2b3aa6e61ab6 100644
--- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
+++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
@@ -470,6 +470,21 @@ &gpi_dma1 {
 	status = "okay";
 };
 
+&gpu {
+	status = "okay";
+};
+
+&gpu_zap_shader {
+	firmware-name = "qcom/sm6350/sony/pdx213/a615_zap.mbn";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	/* PN553 NFC @ 28 */
+};
+
 &i2c8 {
 	clock-frequency = <400000>;
 	status = "okay";
@@ -487,6 +502,17 @@ touchscreen@48 {
 	};
 };
 
+&i2c10 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	/* PM8008 PMIC @ 8 and 9 */
+	/* SMB1395 PMIC @ 34 and 35 */
+	/* AW882xx amplifier @ 34 */
+	/* Foursemi FS16xx amplifier @ 35 */
+	/* FSA4480 Analog Audio Switch @ 42 */
+};
+
 &ipa {
 	firmware-name = "qcom/sm6350/sony/pdx213/ipa_fws.mbn";
 	memory-region = <&pil_ipa_fw_mem>;

-- 
2.53.0

Re: [PATCH v3 12/12] arm64: dts: qcom: sm6350-lena: enable remaining i2c busses

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: sm6350-lena: unrelated and incomplete GPU enablement
- [Medium] arm64: dts: qcom: sm6350-lena: wrong ADC channel in rear_cam_sensor
- [Medium] arm64: dts: qcom: sm6350-lena: invalid led-max-microamp in pm6150l_flash
- [Low] arm64: dts: qcom: sm6350-lena: undocumented unused lcdb_dummy regulator
--

commit dab0552e769e72745a887b1b9b15ebbca1b4c037
Author: erebion <erebion@erebion.eu>

arm64: dts: qcom: sm6350-lena: enable remaining i2c busses

This series enables peripheral, PMIC, thermal, LED, regulator, and bus nodes in the device tree for the Sony Xperia 10 III (sm6350-sony-xperia-lena-pdx213).

> diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> index 6e2bbf4f060ac..d2b3aa6e61ab6 100644
> --- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
[ ... ]
> @@ -44,7 +63,30 @@ key-volume-down {
>  		};
>  	};
>  
> -	touch_en_vreg: touch-en-regulator {
> +	lcdb_dummy: regulator-lcdb-dummy {
> +		compatible = "regulator-fixed";
> +		regulator-name = "lcdb_dummy";
> +		regulator-min-microvolt = <5500000>;
> +		regulator-max-microvolt = <5500000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};

[Severity: Low]
This isn't a bug, but commit e7731bb19fd5 ("arm64: dts: qcom: sm6350-lena:
rename touch-en-regulator") states that it only renames touch-en-regulator
to regulator-touch-en for sorting, while also adding this lcdb_dummy
regulator node.

Nothing in sm6350-sony-xperia-lena-pdx213.dts or sm6350.dtsi references
&lcdb_dummy. Was this node added by mistake, or should it be dropped until a
consumer uses it?

> +
> +	msm_therm_sensor: thermal-sensor-msm {
> +		compatible = "generic-adc-thermal";
> +		#thermal-sensor-cells = <0>;
> +		io-channels = <&pm6150l_adc ADC5_AMUX_THM2_100K_PU>;
> +		io-channel-names = "sensor-channel";
> +	};
> +
> +	rear_cam_sensor: thermal-sensor-rear-cam {
> +		compatible = "generic-adc-thermal";
> +		#thermal-sensor-cells = <0>;
> +		io-channels = <&pm6150l_adc ADC5_GPIO6_100K_PU>;
> +		io-channel-names = "sensor-channel";
> +	};

[Severity: Medium]
Does rear_cam_sensor fail to probe with -EINVAL here?

Under &pm6150l_adc below, the rear_cam_therm channel is defined on
channel@53 with reg = <ADC5_GPIO2_100K_PU> (since GPIO6 on PM6150L routes to
ADC5_GPIO2_100K_PU):

	channel@53 {
		reg = <ADC5_GPIO2_100K_PU>;
		label = "rear_cam_therm";
		qcom,hw-settle-time = <200>;
		qcom,pre-scaling = <1 1>;
		qcom,ratiometric;
	};

However, rear_cam_sensor requests io-channels = <&pm6150l_adc
ADC5_GPIO6_100K_PU>. When gadc_thermal_probe() requests the channel,
adc5_fwnode_xlate() in drivers/iio/adc/qcom-spmi-adc5.c searches the
configured channels on &pm6150l_adc:

	for (i = 0; i < adc->nchannels; i++)
		if (adc->chan_props[i].channel == iiospec->args[0])
			return i;

	return -EINVAL;

Because no channel is registered for ADC5_GPIO6_100K_PU (and
adc5_chans_pmic[] only defines ADC5_GPIO1_100K_PU through
ADC5_GPIO4_100K_PU), adc5_fwnode_xlate() returns -EINVAL and leaves
rear-cam-thermal without a working sensor.

Should rear_cam_sensor use ADC5_GPIO2_100K_PU instead of ADC5_GPIO6_100K_PU?

[ ... ]
> @@ -285,6 +470,21 @@ &gpi_dma1 {
>  	status = "okay";
>  };
>  
> +&gpu {
> +	status = "okay";
> +};
> +
> +&gpu_zap_shader {
> +	firmware-name = "qcom/sm6350/sony/pdx213/a615_zap.mbn";
> +};

[Severity: Medium]
Was enabling &gpu and &gpu_zap_shader intended to be part of commit
dab0552e769e ("arm64: dts: qcom: sm6350-lena: enable remaining i2c busses")?

In addition to not matching the commit description, &mdss in sm6350.dtsi
remains disabled:

		mdss: display-subsystem@ae00000 {
			...
			status = "disabled";

			mdss_mdp: display-controller@ae01000 {
				compatible = "qcom,sm6350-dpu";

With the default drm/msm configuration (separate_gpu_kms = false),
adreno_probe() in drivers/gpu/drm/msm/adreno/adreno_device.c registers a
component and waits for the KMS master on mdss_mdp:

static int adreno_probe(struct platform_device *pdev)
{
	if (of_device_is_compatible(pdev->dev.of_node, "amd,imageon") ||
	    msm_gpu_no_components())
		return msm_gpu_probe(pdev, &a3xx_ops);

	return component_add(&pdev->dev, &a3xx_ops);
}

Because &mdss is disabled, the component master never probes and the GPU
component never binds (and if adreno_remove() runs while unbound,
platform_get_drvdata(pdev) is NULL and dereferencing priv->kms_init crashes).

Should the &gpu and &gpu_zap_shader changes be dropped from this I2C patch?

[ ... ]
> +&pm6150l_flash {
> +	status = "okay";
> +
> +	led-0 {
> +		function = LED_FUNCTION_FLASH;
> +		color = <LED_COLOR_ID_WHITE>;
> +		led-sources = <1>;
> +		led-max-microamp = <1500000>;
> +		flash-max-microamp = <1000000>;
> +		flash-max-timeout-us = <1280000>;
> +	};
> +};

[Severity: Medium]
Is led-max-microamp = <1500000> valid for a single flash channel here?

In Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml,
led-max-microamp (continuous torch current) is limited to 500000 uA for a
single channel or 1000000 uA for dual ganged channels, matching
TORCH_CURRENT_MAX_UA (500000) in drivers/leds/flash/leds-qcom-flash.c:

      led-max-microamp:
        anyOf:
          - minimum: 5000
            maximum: 500000
            multipleOf: 5000
          - minimum: 10000
            maximum: 1000000
            multipleOf: 10000

Setting led-max-microamp to 1500000 uA with led-sources = <1> fails
dtbs_check validation and sets the continuous torch current higher than both
the 500 mA hardware limit and the 1000000 uA flash-max-microamp strobe
current.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-pdx213-upstream-3-v3-0-cdc3be96d257@erebion.eu?part=12

Re: [PATCH v3 12/12] arm64: dts: qcom: sm6350-lena: enable remaining i2c busses

[erebion]

[-- Attachment #1.1: Type: text/plain, Size: 884 bytes --]

On 11/2/26 00:48, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
> - [Medium] arm64: dts: qcom: sm6350-lena: unrelated and incomplete GPU enablement

should not be part of this patch series, will remove

> - [Medium] arm64: dts: qcom: sm6350-lena: wrong ADC channel in rear_cam_sensor

Bot already complained with a reply to the PM6150l thermals patch...

> - [Medium] arm64: dts: qcom: sm6350-lena: invalid led-max-microamp in pm6150l_flash
> - [Low] arm64: dts: qcom: sm6350-lena: undocumented unused lcdb_dummy regulator
> --

Bot already complained with a reply to the flash LED patch...

-- 
erebion

XMPP: erebion@erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the 
aforementioned languages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH v3 12/12] arm64: dts: qcom: sm6350-lena: enable remaining i2c busses

[Konrad Dybcio]

On 11/2/26 12:32 AM, erebion wrote:
> Enable all i2c busses where something is connected on this phone. Add
> comments as placeholders for which components are still missing.
> 
> Signed-off-by: erebion <erebion@erebion.eu>
> ---

Many of these are fairly low-hanging fruits

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad