Skip to contentSkip to conversation

arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng)

PATCH Superseded [email protected] 4 participants 10 messages Jul 21 – Aug 16

Subsystems (3)
Device tree bindings Arm Qualcomm mailing list Arm Qualcomm support

v1 of 6 Superseded Latest is v6 →

lore
Share & tools
lore

[email protected]

author
#0 lore raw

PATCH 1/1 arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng)

From: map220v <[email protected]>

Add device tree for Xiaomi Pad 6S Pro (sheng) based on SM8550.

Signed-off-by code002-2 <[email protected]>
---
 arch/arm64/boot/dts/qcom/Makefile             |    1 +
 .../boot/dts/qcom/sm8550-xiaomi-sheng.dts     | 1800 +++++++++++++++++
 2 files changed, 1801 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts
arch/arm64/boot/dts/qcom/Makefile +1 -0
index 6f33c4e2f..d8e485521 100644
@@ -386,6 +386,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-qrd.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-samsung-q5q.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-sony-xperia-yodo-pdx234.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-xiaomi-sheng.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8650-ayaneo-pocket-s2.dtb
 
 sm8650-hdk-display-card-dtbs	:= sm8650-hdk.dtb sm8650-hdk-display-card.dtbo
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +1800 -0

1,800 lines not on this page · raw message

Signature · 1 line
2.54.0.windows.1
AI review
#1 lore raw
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider: - [Medium] Usage of undocumented out-of-tree bindings and non-standard properties. - [Medium] The second…

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [Medium] Usage of undocumented out-of-tree bindings and non-standard properties.
- [Medium] The second ktz8866 backlight driver will fail to probe due to a shared exclusive GPIO and is orphaned by the display panel.
- [Medium] Redefinition of rmtfs_mem for the modem subsystem despite the modem being disabled.
- [Low] Invalid magic number used in GPIO specifier flags for the touchscreen node.
- [Low] Invalid interrupt trigger type (IRQ_TYPE_NONE) used in the fingerprint node.
- [Low] The vreg_l8b_1p8 regulator is forced always-on for an undocumented device.
--

--- Patch [1]: [PATCH] arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng) --- commit d0e6714197ea1b708f0af6021943e85e81c2c897
Author: map220v <[email protected]>

arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng)

Add device tree for Xiaomi Pad 6S Pro (sheng) based on SM8550.

Quoted 4 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +0 -0
new file mode 100644

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 75

Quoted 4 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +4 -0
+	fingerprint_fpc {
+		compatible = "fpc,fpc1020";
+		interrupt-parent = <&tlmm>;
+		interrupts = <40 0>;

[Severity: Low]
Should this interrupt trigger type be explicitly defined as an edge or level instead of 0 (IRQ_TYPE_NONE)? Hardware interrupt triggers generally need to be explicitly defined to pass dtbs_check validation.

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 77

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+		fpc,gpio_rst = <&tlmm 41 GPIO_ACTIVE_HIGH>;
+		fpc,gpio_irq = <&tlmm 40 GPIO_ACTIVE_HIGH>;

[Severity: Medium]
Are the fpc,fpc1020 compatible string, along with the fpc,gpio_rst and fpc,gpio_irq properties, documented in the upstream bindings? Using undocumented vendor bindings usually triggers dtbs_check validation errors.

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 216

Quoted 8 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +8 -0
+		rmtfs_mem: rmtfs-region@ccd00000 {
+			compatible = "qcom,rmtfs-mem";
+			reg = <0x0 0xccd00000 0x0 0x280000>;
+			no-map;
+
+			qcom,client-id = <1>;
+			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
+		};

[Severity: Medium]
Since the modem subsystem nodes are explicitly deleted because the SM8550P lacks a modem DSP, is it necessary to recreate the rmtfs_mem reservation and assign it to the modem VMID?

Could this cause SCM assignment errors on hardware lacking the modem DSP, or unnecessarily reserve 2.5MB of RAM?

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 502

Quoted 9 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +9 -0
+		/* Xiaomi change for Semtech SX9371 */
+		vreg_l8b_1p8: ldo8 {
+			regulator-name = "vreg_l8b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-always-on;
+			regulator-boot-on;
+		};

[Severity: Low]
Is it intentional to force this regulator always-on when there doesn't appear to be a Semtech SX9371 consumer node defined in the device tree? Could this circumvent runtime power management for this regulator?

[ ... ]

Quoted 8 lines

+&i2c1 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +7 -0
+	status = "okay";
+
+	backlight: backlight@11 {
+		compatible = "kinetic,ktz8866a";
+		reg = <0x11>;
+		vin-supply = <&vph_pwr>;
+		enable-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1195

Quoted 5 lines

+&i2c9 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +4 -0
+	status = "okay";
+
+	nanosic_mcu@4c {
+		compatible = "nanosic,wn8030-sheng";

[Severity: Medium]
Is the nanosic,wn8030-sheng compatible string documented upstream?

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1224

Quoted 8 lines

+&i2c_hub_2 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +7 -0
+	status = "okay";
+
+	backlight@11 {
+		compatible = "kinetic,ktz8866b";
+		reg = <0x11>;
+		vin-supply = <&vph_pwr>;
+		enable-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;

[Severity: Medium]
Will this second backlight driver fail to probe with -EBUSY since both instances request the same exclusive GPIO from tlmm?

Also, since the display panel node only holds a phandle to the first backlight, will this second instance remain orphaned and uncontrolled?

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1515

Quoted 9 lines

+&spi4 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +8 -0
+	status = "okay";
+
+	touchscreen@0 {
+		compatible = "novatek,NVT-ts-spi";
+		reg = <0>;
+
+		spi-max-frequency = <19200000>;
+		novatek,irq-gpio = <&tlmm 25 0x2001>;

[Severity: Low]
Does the GPIO specifier flag 0x2001 contain an undocumented downstream bit? Standard dt-bindings define GPIO_ACTIVE_LOW as 1, so 0x2000 might cause validation warnings upstream.

[Severity: Medium]
Are the novatek,NVT-ts-spi compatible and novatek,irq-gpio property documented upstream?

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
#2 lore raw
In reply to [email protected]
Quoted 6 lines · On 7/21/26 3:32 PM, [email protected] wrote:

From: map220v <[email protected]>

Add device tree for Xiaomi Pad 6S Pro (sheng) based on SM8550.

Signed-off-by code002-2 <[email protected]>

---

[...]

Quoted 7 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +7 -0
+/*
+ * Free unused regions, these regions don't exist in downstream
+ * dts, and they aren't removed from DDR Memory Map by UEFI.
+ */
+/delete-node/ &hyp_tags_reserved_mem;
+/delete-node/ &cdsp_secure_heap_mem;
+/delete-node/ &trust_ui_vm_mem;

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 41

Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +10 -0
+/delete-node/ &trust_ui_vm_dump;
+/delete-node/ &trust_ui_vm_qrtr;
+/delete-node/ &trust_ui_vm_vblk0_ring;
+/delete-node/ &trust_ui_vm_vblk1_ring;
+/delete-node/ &trust_ui_vm_swiotlb;
+/delete-node/ &oem_vm_vblk0_ring;
+/delete-node/ &oem_vm_swiotlb;
+/delete-node/ &oem_vm_mem;
+/delete-node/ &hyp_ext_tags_mem;
+/delete-node/ &hyp_ext_reserved_mem;

I think all of them can be removed from the SoC DTSI

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 47

Quoted 5 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +5 -0
+/* Xiaomi uses alternative gpio's for i2c8 */
+/delete-node/ &qup_i2c8_data_clk;
+
+/* Xiaomi change for Nanosic WN803x */
+/delete-node/ &qup_i2c9_data_clk;

The change here seems to just be a difference in pull-up

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 53

Quoted 6 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +6 -0
+
+/* SM8550P doesn't have Modem DSP */
+/delete-node/ &mpss_dsm_mem;
+/delete-node/ &mpss_mem;
+/delete-node/ &q6_mpss_dtb_mem;
+/delete-node/ &remoteproc_mpss;

I'm not sure that's true. Have you tried booting it up?

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 59

Quoted 5 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +5 -0
+/ {
+	model = "Xiaomi Pad 6S Pro 12.4";
+	compatible = "xiaomi,sheng", "qcom,sm8550";
+	chassis-type = "tablet";
+	qcom,msm-id = <536 0x20000>; /* SM8550P v2.0 */

Please define it in include/dt-bindings/arm/qcom,ids.h and use the define here But you shouldn't need msm-id on non-ancient hardware

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 70

Quoted 11 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +11 -0
+	qcom,board-id = <0x10008 0>;
+
+	aliases {
+		serial0 = &uart7;
+		serial1 = &uart14;
+	};
+
+	chosen {
+		/* Required for libcamera to allocate buffers when udmabuf is used. */
+		bootargs = "udmabuf.size_limit_mb=256";
+	};

Is this actually necessary?

Review

Quoted 2 lines
(quoted diff) +2 -0
+
+	fingerprint_fpc {

Node names must not contain underscores and should be generic. fingerprint-reader {} sounds good

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 73

Quoted 1 line
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +1 -0
+		compatible = "fpc,fpc1020";

This compatible doesn't exist in the tree.

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 75

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+		interrupt-parent = <&tlmm>;
+		interrupts = <40 0>;

interrupts-extended = <&tlmm 40 IRQ_TYPE_PLEASEFIX>;

[...]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 146

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+	pmic-glink {
+		compatible = "xiaomi,sm8550-pmic-glink", "qcom,sm8550-pmic-glink", "qcom,pmic-glink";

1 per line, please

[...]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 262

Quoted 8 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +8 -0
+		secondary-i2s-dai-link {
+			link-name = "Secondary MI2S Playback";
+
+			cpu {
+				sound-dai = <&q6apmbedai SECONDARY_MI2S_RX>;
+			};
+
+			codec {

'co'dec < 'cp'u

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 264

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+				sound-dai = <&cs35l43_tll>, <&cs35l43_tlh>, <&cs35l43_trl>,
+							<&cs35l43_bll>, <&cs35l43_blh>, <&cs35l43_brl>;

Please align (set your tab width to 8)

[...]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 331

Quoted 1 line
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +1 -0
+	wcd938x: audio-codec {

Nodes without a unit address should be sorted by name

https://docs.kernel.org/devicetree/bindings/dts-coding-style.html

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 335

Quoted 4 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +4 -0
+		compatible = "qcom,wcd9380-codec";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&wcd_default>;

property-n
property-names

in this order, file-wide please

[...]

Review

Quoted 1 line
(quoted diff) +1 -0
+		/* Xiaomi change for Camera Modules */

I don't think these comments are valuable.

[...]

Quoted 4 lines

+&cci0_i2c1 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +3 -0
+	clock-frequency = <1000000>;
+
+	camera@10 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 883

Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +10 -0
+		compatible = "samsung,s5kjn1";
+		reg = <0x10>;
+
+		reset-gpios = <&tlmm 118 GPIO_ACTIVE_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&cam2_default>, <&cam_rear_reset_default>;
+
+		clocks = <&camcc CAM_CC_MCLK2_CLK>;
+
+		orientation = <1>;

Please use a define from:

https://lore.kernel.org/linux-arm-msm/[email protected]/

Quoted 9 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +9 -0
+		rotation = <0>;
+
+		lens-focus = <&gt9764>;
+
+		vddio-supply = <&vreg_l4b_1p8>;
+		vddd-supply = <&vreg_l2m_1p08>;
+		vdda-supply = <&vreg_l4m_2p8>;
+
+		port {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 902

Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +10 -0
+			s5kjn1_ep: endpoint {
+				data-lanes = <0 1 2 3>;
+				link-frequencies = /bits/ 64 <857600000>;
+				remote-endpoint = <&csiphy3_ep>;
+			};
+		};
+	};
+
+	gt9764: camera-lens@c {
+		compatible = "giantec,gt9764";

This compatible doesn't exist in the tree

[...]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 979

Quoted 3 lines

+&ipa {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+	qcom,gsi-loader = "self";
+	memory-region = <&ipa_fw_mem>;

Please rebase atop

https://lore.kernel.org/linux-arm-msm/[email protected]/

This is in -next already, so I'm worried you're not working on linux-next/master.

Review

Quoted 2 lines
(quoted diff) +2 -0
+	firmware-name = "qcom/sm8550/sheng/ipa_fws.mbn";
+	status = "okay";

Please keep a \n above 'status', uniformly

[...]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 997

Quoted 2 lines

+&gpu_zap_shader {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +1 -0
+	firmware-name = "qcom/sm8550/sheng/a740_zap.mbn";

Paths should contain the name of the vendor

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1005

Quoted 8 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +8 -0
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	typec-retimer@28 {
+		compatible = "parade,ps5169";

This compatible doesn't exist in the tree.

[...]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1044

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+	backlight: backlight@11 {
+		compatible = "kinetic,ktz8866a";

This compatible doesn't exist in the tree.

Quoted 6 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +6 -0
+		reg = <0x11>;
+		vin-supply = <&vph_pwr>;
+		enable-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
+		current-num-sinks = <5>;
+		kinetic,current-ramp-delay-ms = <256>;
+		kinetic,led-enable-ramp-delay-ms = <8>;

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1060

Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +10 -0
+		kinetic,enable-lcd-bias;
+	};
+};
+
+&i2c5 {
+	clock-frequency = <1000000>;
+	status = "okay";
+
+	cs35l43_trl: cs35l43@40 {
+		compatible = "cirrus,cs35l43";

This compatible doesn't exist in the tree.

[...]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1195

Quoted 5 lines

+&i2c9 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +4 -0
+	status = "okay";
+
+	nanosic_mcu@4c {
+		compatible = "nanosic,wn8030-sheng";

This compatible doesn't exist in the tree.

[...]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1221

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+	backlight@11 {
+		compatible = "kinetic,ktz8866b";

This compatible doesn't exist in the tree.

[...]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1266

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+	display_panel: panel@0 {
+		compatible = "xiaomi,sheng-nt36532e", "novatek,nt36532e";

This compatible doesn't exist in the tree.

[...]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1511

Quoted 5 lines

+&spi4 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +4 -0
+	status = "okay";
+
+	touchscreen@0 {
+		compatible = "novatek,NVT-ts-spi";

This compatible definitely doesn't exist in the tree.

[...]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1636

Quoted 6 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +6 -0
+	wcd_default: wcd-reset-n-active-state {
+		pins = "gpio108";
+		function = "gpio";
+		drive-strength = <16>;
+		bias-disable;
+		output-low;

Remove output- properties from TLMM pins. The consumer drivers will call the appropriate GPIOD APIs

Konrad

author
#3 lore raw

PATCH v3 1/1 arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng)

In reply to [email protected]

From: map220v <[email protected]>

Add device tree for Xiaomi Pad 6S Pro (sheng) based on SM8550.

Signed-off-by code002-2 <[email protected]>

---
v3: address review comments from Konrad Dybcio
- SM8550P has no modem; confirmed on device (dmesg shows no mpss)
- Rename fingerprint_fpc -> fingerprint-reader, use interrupts-extended
- pmic-glink compatibles: one per line
- Sort DAI link subnodes alphabetically (codec before cpu)
- Reorder root-level nodes by name
- Place pinctrl-n properties before pinctrl-names
- Remove msm-id, board-id, Xiaomi-specific comments
- Remove output-low/output-high from TLMM pinctrl
- Remove udmabuf bootargs (confirmed not in use on device)
- Add "xiaomi-" prefix to firmware paths

---
 arch/arm64/boot/dts/qcom/Makefile             |    1 +
 .../boot/dts/qcom/sm8550-xiaomi-sheng.dts     | 1763 +++++++++++++++++
 2 files changed, 1764 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts
arch/arm64/boot/dts/qcom/Makefile +1 -0
index 6f33c4e2f..d8e485521 100644
@@ -386,6 +386,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-qrd.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-samsung-q5q.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-sony-xperia-yodo-pdx234.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-xiaomi-sheng.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8650-ayaneo-pocket-s2.dtb
 
 sm8650-hdk-display-card-dtbs	:= sm8650-hdk.dtb sm8650-hdk-display-card.dtbo
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +1763 -0

1,763 lines not on this page · raw message

Signature · 1 line
2.54.0.windows.1
author
#4 lore raw

PATCH v4 1/1 arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng)

From: map220v <[email protected]>

Add device tree for Xiaomi Pad 6S Pro (sheng) based on SM8550.

Signed-off-by code002-2 <[email protected]>

---

v4: address Sashiko AI review comments
- Add GPIO_OPEN_DRAIN to shared cs35l43 reset-gpios to avoid -EBUSY
- Set Bluetooth local-bd-address to [ 00 00 00 00 00 00 ]

v3: address review comments from Konrad Dybcio
- SM8550P has no modem; confirmed on device (dmesg shows no mpss)
- Rename fingerprint_fpc -> fingerprint-reader, use interrupts-extended
- pmic-glink compatibles: one per line
- Sort DAI link subnodes alphabetically (codec before cpu)
- Reorder root-level nodes by name
- Place pinctrl-n properties before pinctrl-names
- Remove msm-id, board-id, Xiaomi-specific comments
- Remove output-low/output-high from TLMM pinctrl
- Remove udmabuf bootargs (confirmed not in use on device)
- Add "xiaomi-" prefix to firmware paths

---
 arch/arm64/boot/dts/qcom/Makefile             |    1 +
 .../boot/dts/qcom/sm8550-xiaomi-sheng.dts     | 1763 +++++++++++++++++
 2 files changed, 1764 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts
arch/arm64/boot/dts/qcom/Makefile +1 -0
index 6f33c4e2f..d8e485521 100644
@@ -386,6 +386,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-qrd.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-samsung-q5q.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-sony-xperia-yodo-pdx234.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-xiaomi-sheng.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8650-ayaneo-pocket-s2.dtb
 
 sm8650-hdk-display-card-dtbs	:= sm8650-hdk.dtb sm8650-hdk-display-card.dtbo
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +1763 -0

1,763 lines not on this page · raw message

Signature · 1 line
2.54.0.windows.1
author
#5 lore raw

PATCH v5 1/1 arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng)

From: map220v <[email protected]>

Add device tree for Xiaomi Pad 6S Pro (sheng) based on SM8550.

Signed-off-by code002-2 <[email protected]>

---
v5: address additional Sashiko AI review on v3/v4
- Add assigned-clocks alongside assigned-clock-parents in mdss_dsi1
- Actually remove output-high from i2s1_default pinctrl (missed in v3)

v4: address Sashiko AI review comments
- Add GPIO_OPEN_DRAIN to shared cs35l43 reset-gpios to avoid -EBUSY
- Set Bluetooth local-bd-address to [ 00 00 00 00 00 00 ]

v3: address review comments from Konrad Dybcio
- SM8550P has no modem; confirmed on device (dmesg shows no mpss)
- Rename fingerprint_fpc -> fingerprint-reader, use interrupts-extended
- pmic-glink compatibles: one per line
- Sort DAI link subnodes alphabetically (codec before cpu)
- Reorder root-level nodes by name
- Place pinctrl-n properties before pinctrl-names
- Remove msm-id, board-id, Xiaomi-specific comments
- Remove output-low/output-high from TLMM pinctrl
- Remove udmabuf bootargs (confirmed not in use on device)
- Add "xiaomi-" prefix to firmware paths

---
 arch/arm64/boot/dts/qcom/Makefile             |    1 +
 .../boot/dts/qcom/sm8550-xiaomi-sheng.dts     | 1761 +++++++++++++++++
 2 files changed, 1762 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts
arch/arm64/boot/dts/qcom/Makefile +1 -0
index 6f33c4e2f..d8e485521 100644
@@ -386,6 +386,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-qrd.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-samsung-q5q.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-sony-xperia-yodo-pdx234.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-xiaomi-sheng.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8650-ayaneo-pocket-s2.dtb
 
 sm8650-hdk-display-card-dtbs	:= sm8650-hdk.dtb sm8650-hdk-display-card.dtbo
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +1761 -0

1,761 lines not on this page · raw message

Signature · 1 line
2.54.0.windows.1
AI review
#6 lore raw
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider: - [High] Invalid clock reparenting for dual DSI synchronization. - [High] Using `GPIO_OPEN_DRAIN` does not…

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Invalid clock reparenting for dual DSI synchronization.
- [High] Using GPIO_OPEN_DRAIN does not bypass gpiolib's exclusive access check for shared reset lines.
- [High] Severe overvoltage risk by configuring a 0.7V-named regulator to 1.9V.
- [Medium] Asymmetric speaker assignment breaks stereo audio routing.
- [Medium] Unnecessary memory allocation for non-existent modem RMTFS.
- [Low] Use of undocumented and downstream DT bindings.
--

--- Patch [1]: [PATCH v5] arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng) --- commit 84985aa6cc3ea47e6961c9fece55de9d4418b9fc
Author: map220v <[email protected]>

arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng)

Add device tree for Xiaomi Pad 6S Pro (sheng) based on SM8550.

Quoted 2 lines

v4: address Sashiko AI review comments
- Add GPIO_OPEN_DRAIN to shared cs35l43 reset-gpios to avoid -EBUSY

[Severity: High]
Will this still result in -EBUSY errors for 5 out of the 6 speaker amplifiers?

Adding GPIO_OPEN_DRAIN is an electrical configuration and does not instruct gpiolib to bypass exclusive access checks.

Quoted 4 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +0 -0
new file mode 100644

[ ... ]

Quoted 1 line
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +1 -0
+	reserved-memory {

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 233

Quoted 7 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +7 -0
+		rmtfs_mem: rmtfs-region@ccd00000 {
+			compatible = "qcom,rmtfs-mem";
+			reg = <0x0 0xccd00000 0x0 0x280000>;
+			no-map;
+
+			qcom,client-id = <1>;
+		};

[Severity: Medium]
Is this reserved memory region necessary?

The commit message notes the device lacks a modem, but this node allocates memory for client-id 1, which strictly maps to the MPSS remote file system client.

[ ... ]

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+	regulators-5 {
+		compatible = "qcom,pm8550vs-rpmh-regulators";

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 696

Quoted 4 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +4 -0
+		vreg_s3g_0p7: smps3 {
+			regulator-name = "vreg_s3g_0p7";
+			regulator-min-microvolt = <600000>;
+			regulator-max-microvolt = <1900000>; //2004000

[Severity: High]
Could this create an overvoltage risk for other hardware relying on a 0.7V rail?

The regulator node name implies a nominally 0.7V rail, but it allows up to 1.9V. If this is a dedicated 1.8V rail, should the node be renamed to reflect the hardware reality and prevent unsafe reuse?

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1041

Quoted 10 lines

+&i2c5 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +9 -0
+	clock-frequency = <1000000>;
+	status = "okay";
+
+	cs35l43_trl: cs35l43@40 {
+		compatible = "cirrus,cs35l43";
+		reg = <0x40>;
+		interrupt-parent = <&tlmm>;
+		interrupts = <98 IRQ_TYPE_LEVEL_LOW>;
+		reset-gpios = <&tlmm 90 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;

[Severity: High]
Does this properly bypass gpiolib's exclusive access check for shared reset lines?

Setting GPIO_OPEN_DRAIN alone does not bypass exclusive access, so devices probing after the first one might still receive -EBUSY.

Quoted 1 line
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +1 -0
+		#sound-dai-cells = <0>;

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1112

Quoted 13 lines

+&i2c8 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +12 -0
+	clock-frequency = <1000000>;
+	status = "okay";
+
+	cs35l43_blh: cs35l43@40 {
+		compatible = "cirrus,cs35l43";
+		reg = <0x40>;
+		interrupt-parent = <&tlmm>;
+		interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+		reset-gpios = <&tlmm 90 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+		#sound-dai-cells = <0>;
+		sound-name-prefix = "BLH";
+		cirrus,dsp-part-name = "blh-cs35l43";

[Severity: Medium]
Does this asymmetric speaker assignment break stereo audio routing?

There are left-side tweeter nodes defined (TLH and BLH) but no right-side high speakers, which seems to create an asymmetric 4-left / 2-right topology.

Quoted 1 line
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +1 -0
+		cirrus,vpbr-thld = <8>;

[ ... ]

Quoted 6 lines

+&mdss_dsi0 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +5 -0
+	vdda-supply = <&vreg_l3e_1p2>;
+	qcom,dual-dsi-mode;
+	qcom,sync-dual-dsi;
+	qcom,master-dsi;
+	status = "okay";

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1239

Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +10 -0
+
+	display_panel: panel@0 {
+		compatible = "xiaomi,sheng-nt36532e", "novatek,nt36532e";
+		reg = <0>;
+
+		pinctrl-0 = <&sde_dsi_active>;
+		pinctrl-1 = <&sde_dsi_suspend>;
+		pinctrl-names = "default", "sleep";
+
+		vddio-supply = <&vreg_s3g_0p7>;

[Severity: High]
Is it safe to assign a nominally 0.7V regulator to the display panel's vddio-supply here? This usage forces the voltage to the higher 1.9V limit.

Quoted 1 line
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +1 -0
+		avdd-supply = <&bl_vddpos_5p8>;

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1285

Quoted 7 lines

+&mdss_dsi1 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +6 -0
+	vdda-supply = <&vreg_l3e_1p2>;
+	qcom,dual-dsi-mode;
+	qcom,sync-dual-dsi;
+	/* DSI1 is slave, so use DSI0 clocks */
+	assigned-clocks = <&mdss_dsi1_phy 0>, <&mdss_dsi1_phy 1>;
+	assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>;

[Severity: High]
Will this clock reparenting fail during probe and break dual display initialization?

DSI PHY PLL output clocks are fixed to their local PLLs and do not have configurable parents. Shouldn't the consumer dispcc clocks be parented to the master PHY's outputs to properly sync dual DSI?

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+	status = "okay";
+};

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1482

Quoted 9 lines

+&spi4 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +8 -0
+	status = "okay";
+
+	touchscreen@0 {
+		compatible = "novatek,NVT-ts-spi";
+		reg = <0>;
+
+		spi-max-frequency = <19200000>;
+		novatek,irq-gpio = <&tlmm 25 GPIO_ACTIVE_LOW>;

[Severity: Low]
Will these undocumented downstream compatibles and properties fail dtbs_check and prevent standard upstream drivers from binding?

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+
+		panel = <&display_panel>;
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
AI review
#7 lore raw
In reply to [email protected]
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider: - [High] Adding GPIO_OPEN_DRAIN to shared reset-gpios does not bypass the gpiolib exclusive request check…

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Adding GPIO_OPEN_DRAIN to shared reset-gpios does not bypass the gpiolib exclusive request check, causing subsequent codec probes to fail with -EBUSY.
- [High] The reset-gpios for cs35l43 codecs use GPIO_ACTIVE_HIGH, which inverts the required active-low reset polarity.
- [High] Invalid compatible string kinetic,ktz8866a prevents the backlight driver from probing.
- [High] Missing pinctrl configurations for critical interrupt and reset GPIOs, which may leave inputs floating.
- [Medium] The commit violates the kernel's Developer Certificate of Origin (DCO) and Submitting Patches guidelines regarding identity and chain of custody.
- [Medium] The output-high properties were incorrectly applied to hardware-muxed pins in i2s1_default and were not removed as claimed in the changelog. --

--- Patch [1]: [PATCH v4] arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng) --- commit 67dc6a3d188573154b653dea21a66bad2811a5b2
Author: map220v <[email protected]>

arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng)

Add device tree for Xiaomi Pad 6S Pro (sheng) based on SM8550.

Quoted 1 line

Author: map220v <[email protected]>

[ ... ]

Quoted 1 line
Signed-off-by code002-2 <[email protected]>

[Severity: Medium]
Do these identities meet the kernel's Developer Certificate of Origin (DCO) requirements? Both the Author and the Signed-off-by tags appear to use pseudonyms.

Furthermore, the Author's identity is missing from the Signed-off-by chain, which breaks the custody tracking.

Quoted 4 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +0 -0
new file mode 100644

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1021

Quoted 5 lines

+&i2c1 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +4 -0
+	status = "okay";
+
+	backlight: backlight@11 {
+		compatible = "kinetic,ktz8866a";

[Severity: High]
Does the upstream Kinetic KTZ8866 backlight driver recognize the 'a' suffix?

The driver in drivers/video/backlight/ktz8866.c and its bindings seem to only support "kinetic,ktz8866". Without a fallback, could this silently fail to probe and leave the display unlit?

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1041

Quoted 10 lines

+&i2c5 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +9 -0
+	clock-frequency = <1000000>;
+	status = "okay";
+
+	cs35l43_trl: cs35l43@40 {
+		compatible = "cirrus,cs35l43";
+		reg = <0x40>;
+		interrupt-parent = <&tlmm>;
+		interrupts = <98 IRQ_TYPE_LEVEL_LOW>;
+		reset-gpios = <&tlmm 90 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;

[Severity: High]
Does adding GPIO_OPEN_DRAIN bypass the gpiolib exclusive request check?

Since all six cs35l43 codec nodes share this exact reset GPIO, gpiolib will likely return -EBUSY for all subsequent codec probes after the first one succeeds.

[Severity: High]
Also, does (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN) invert the intended active-low reset polarity?

By specifying GPIO_ACTIVE_HIGH, gpiolib will translate a driver's logical 0 into a physical LOW, which might hold the codecs in reset permanently.

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1481

Quoted 9 lines

+&spi4 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +8 -0
+	status = "okay";
+
+	touchscreen@0 {
+		compatible = "novatek,NVT-ts-spi";
+		reg = <0>;
+
+		spi-max-frequency = <19200000>;
+		novatek,irq-gpio = <&tlmm 25 GPIO_ACTIVE_LOW>;

[Severity: High]
Is a pinctrl configuration missing for this interrupt pin?

The device tree relies on interrupt pins like gpio25 for the touchscreen, gpio62 for the MCU, codec interrupts, and the shared reset pin gpio90, but fails to define and attach pinctrl states for them.

Leaving interrupt pins floating without explicit biases risks spurious interrupt storms, and unconfigured outputs risk failing to reset hardware correctly.

[ ... ]

Quoted 22 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +22 -0
+	i2s1_default: i2s1-default-state {
+		sck-pins {
+			pins = "gpio121";
+			function = "i2s1_sck";
+			drive-strength = <8>;
+			bias-disable;
+			output-high;
+		};
+
+		data0-pins {
+			pins = "gpio122";
+			function = "i2s1_data0";
+			drive-strength = <8>;
+			bias-disable;
+		};
+
+		ws-pins {
+			pins = "gpio123";
+			function = "i2s1_ws";
+			drive-strength = <8>;
+			bias-disable;
+			output-high;

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1633

Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +10 -0
+		};
+
+		data1-pins {
+			pins = "gpio124";
+			function = "i2s1_data1";
+			drive-strength = <8>;
+			bias-disable;
+			output-high;
+		};
+	};

[Severity: Medium]
Are these output-high properties correctly applied to hardware-muxed pins?

In Qualcomm pinctrl, static output states should typically only be configured when function = "gpio". Applying output-high to hardware-driven pins can conflict with the hardware controller block.

The commit message also mentions removing output-low/output-high from TLMM pinctrls, but they appear to still be present here.

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
AI review
#8 lore raw
In reply to [email protected]
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider: - [High] Missing `assigned-clocks` property in `mdss_dsi1` causes `assigned-clock-parents` to be silently…

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Missing assigned-clocks property in mdss_dsi1 causes assigned-clock-parents to be silently ignored.
- [High] The device tree hardcodes a specific Bluetooth MAC address, leaking the author's device MAC and causing network collisions for all users.
- [Medium] Introduction of downstream-specific, undocumented bindings and structurally invalid node placement.
- [Medium] The patch retains output-high in the i2s1_default pinctrl state despite the commit message claiming its removal. --

--- Patch [1]: [PATCH v3] arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng) --- commit a32cafba2cc54395e026266ce89446c6ffa392e4
Author: map220v <[email protected]>

arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng)

Add device tree for Xiaomi Pad 6S Pro (sheng) based on SM8550.

Quoted 10 lines

---
v3: address review comments from Konrad Dybcio
- SM8550P has no modem; confirmed on device (dmesg shows no mpss)
- Rename fingerprint_fpc -> fingerprint-reader, use interrupts-extended
- pmic-glink compatibles: one per line
- Sort DAI link subnodes alphabetically (codec before cpu)
- Reorder root-level nodes by name
- Place pinctrl-n properties before pinctrl-names
- Remove msm-id, board-id, Xiaomi-specific comments
- Remove output-low/output-high from TLMM pinctrl

[Severity: Medium]
Is this description accurate? The output-high property is still present in the i2s1_default pinctrl state below.

Quoted 7 lines

- Remove udmabuf bootargs (confirmed not in use on device)
- Add "xiaomi-" prefix to firmware paths

---
 arch/arm64/boot/dts/qcom/Makefile             |    1 +
 .../boot/dts/qcom/sm8550-xiaomi-sheng.dts     | 1763 +++++++++++++++++
 2 files changed, 1764 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 111

Quoted 13 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +13 -0
+	bl_vddpos_5p8: bl-vddpos-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "bl_vddpos_5p8";
+		regulator-min-microvolt = <5800000>;
+		regulator-max-microvolt = <5800000>;
+		regulator-enable-ramp-delay = <233>;
+		gpio = <&tlmm 30 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	fingerprint-reader {
+		compatible = "fpc,fpc1020";
+		interrupts-extended = <&tlmm 40 IRQ_TYPE_EDGE_RISING>;

[Severity: Medium]
Should this node be placed under its corresponding hardware bus instead of at the root level? Also, does this use an undocumented downstream compatible?

Quoted 2 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +2 -0
+		fpc,gpio_rst = <&tlmm 41 GPIO_ACTIVE_HIGH>;
+		fpc,gpio_irq = <&tlmm 40 GPIO_ACTIVE_HIGH>;

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1284

Quoted 6 lines

+&mdss_dsi1 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +5 -0
+	vdda-supply = <&vreg_l3e_1p2>;
+	qcom,dual-dsi-mode;
+	qcom,sync-dual-dsi;
+	/* DSI1 is slave, so use DSI0 clocks */
+	assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>;

[Severity: High]
Will assigned-clock-parents be silently ignored here without an assigned-clocks property to specify which clocks should receive the new parents?

Quoted 2 lines
(quoted diff) +2 -0
+	status = "okay";
+};

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1172

Quoted 5 lines

+&i2c9 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +4 -0
+	status = "okay";
+
+	nanosic_mcu@4c {
+		compatible = "nanosic,wn8030-sheng";

[Severity: Medium]
Is this an upstream-supported compatible string, or does this use an undocumented downstream binding?

Quoted 3 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +3 -0
+		reg = <0x4c>;
+
+		pinctrl-0 = <&nanosic_mcu_default>;

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1477

Quoted 5 lines

+&spi4 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +4 -0
+	status = "okay";
+
+	touchscreen@0 {
+		compatible = "novatek,NVT-ts-spi";

[Severity: Medium]
Does this use an undocumented downstream compatible for the touchscreen?

Quoted 3 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +3 -0
+		reg = <0>;
+
+		spi-max-frequency = <19200000>;

[ ... ]

Quoted 5 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +5 -0
+	wcd_default: wcd-reset-n-active-state {
+		pins = "gpio108";
+		function = "gpio";
+		drive-strength = <16>;
+		bias-disable;

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1609

Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +10 -0
+	};
+
+	i2s1_default: i2s1-default-state {
+		sck-pins {
+			pins = "gpio121";
+			function = "i2s1_sck";
+			drive-strength = <8>;
+			bias-disable;
+			output-high;
+		};

[Severity: Medium]
Is the output-high property intended here? The commit message mentions this was removed, and setting an output level on a pin configured for an alternate function like i2s1_sck might be invalid.

Quoted 3 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +3 -0
+
+		data0-pins {
+			pins = "gpio122";

[ ... ]

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts line 1701

Quoted 7 lines

+&uart14 {

arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +6 -0
+	status = "okay";
+
+	bluetooth {
+		compatible = "qcom,wcn7850-bt";
+
+		local-bd-address = [ 24 00 00 00 5a ad ];

[Severity: High]
Does hardcoding local-bd-address cause all users of this device tree to broadcast the same Bluetooth MAC address? This could cause network collisions if multiple devices are nearby. Should this be zeroed out or removed so the bootloader can populate it?

Quoted 3 lines
arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts new file +3 -0
+
+		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+		vddaon-supply = <&vreg_pmu_aon_0p59>;
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
build bot
#9 lore raw
In reply to [email protected]
kernel test robot noticed the following build errors:

Hi,

kernel test robot noticed the following build errors:

[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v7.2-rc7 next-20260814] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/code_0002-163-com/arm64-dts-qcom-sm8550-add-Xiaomi-Pad-6S-Pro-sheng/20260815-144756
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link:    https://lore.kernel.org/r/20260721133204.902-1-code_0002%40163.com
patch subject: [PATCH] arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng)
config: arm64-randconfig-004-20260816 (https://download.01.org/0day-ci/archive/20260816/[email protected]/config)
compiler: aarch64-linux-gcc (GCC) 10.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260816/[email protected]/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

All errors (new ones prefixed by >>):

Error: arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts:947.1-11 Label or path cci1_i2c1 not found

>> FATAL ERROR: Syntax error parsing input tree

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki