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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Multiple `cs35l43` audio amplifiers share the exact same `reset-gpios` without non-exclusive flags.
- [High] Specific hardcoded Bluetooth MAC address in the device tree.
- [Low] Several nodes use undocumented compatible strings that lack upstream bindings and drivers, and the backlight node violates existing bindings.
--

--- Patch [1]: [PATCH v2] arm64: dts: qcom: sm8550: add Xiaomi Pad 6S Pro (sheng) ---
commit 60dbe1c9d61443d5cd6de8980b141b0f56a24a53
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
> index 0000000000000..170a67b37b7a6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sm8550-xiaomi-sheng.dts

[ ... ]

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

[Severity: Low]
Are the compatible strings for this node and display_panel (kinetic,ktz8866a
and novatek,nt36532e) planned to be documented upstream? Without bindings,
these out-of-tree compatible strings will generate warnings during dtbs_check
validation.

[ ... ]

> +&i2c5 {
> +	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>;

[Severity: High]
Since multiple cs35l43 amplifier instances all specify the exact same
reset-gpios, won't the GPIO subsystem's exclusive access guarantees grant the
GPIO to the first probing instance? 

It seems the other instances will fail to probe with -EBUSY, which would
break the other audio amplifiers on the device. Might a gpio-reset controller
node be needed to share the reset GPIO correctly?

[ ... ]

> +&uart14 {
> +	status = "okay";
> +
> +	bluetooth {
> +		compatible = "qcom,wcn7850-bt";
> +
> +		local-bd-address = [ 24 00 00 00 5a ad ];

[Severity: High]
If the bootloader fails to dynamically overwrite this property on production
units, won't all devices running this kernel share the exact same Bluetooth
MAC address? Using [ 00 00 00 00 00 00 ] is standard practice to ensure
bootloader patch failure is obvious and doesn't lead to widespread MAC
collisions.

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