Re: [PATCH] arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng)

[sashiko-bot@kernel.org]

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 <map220v300@gmail.com>

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

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

> diff --git a/arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts b/arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts

[ ... ]

> +	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.

> +		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.

[ ... ]

> +		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?

[ ... ]

> +		/* 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?

[ ... ]

> +&i2c1 {
> +	status = "okay";
> +
> +	backlight: backlight@11 {
> +		compatible = "kinetic,ktz8866a";
> +		reg = <0x11>;
> +		vin-supply = <&vph_pwr>;
> +		enable-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;

[ ... ]

> +&i2c9 {
> +	status = "okay";
> +
> +	nanosic_mcu@4c {
> +		compatible = "nanosic,wn8030-sheng";

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

[ ... ]

> +&i2c_hub_2 {
> +	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?

[ ... ]

> +&spi4 {
> +	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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721133204.902-1-code_0002@163.com?part=1