Re: [PATCH v3 3/3] arm64: dts: qcom: sm8650: fix soundwire ports properties

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Prepending an element to the `qcom,ports-*` arrays for `swr2` shifts the configuration indices, corrupting the SoundWire Master Port configurations for the TX codec.
--

commit a1c9b1d54073d838cfb9e5474d5c6e26f81803b9
Author: Neil Armstrong <neil.armstrong@linaro.org>

arm64: dts: qcom: sm8650: fix soundwire ports properties

This commit updates the soundwire port counts and properties to match the
actual hardware configuration, addressing deprecation warnings for din/out
ports.

> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index 090a4739ebc1d..b1293fdb1481c 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi

[ ... ]

> @@ -4831,17 +4831,17 @@ swr2: soundwire@6d30000 {
>  			pinctrl-names = "default";
>  
>  			qcom,din-ports = <4>;
> -			qcom,dout-ports = <0>;
> -
> -			qcom,ports-sinterval-low =	/bits/ 8 <0x01 0x01 0x03 0x03>;
> -			qcom,ports-offset1 =		/bits/ 8 <0x00 0x00 0x01 0x01>;
> -			qcom,ports-offset2 =		/bits/ 8 <0x00 0x00 0x00 0x00>;
> -			qcom,ports-hstart =		/bits/ 8 <0xff 0xff 0xff 0xff>;
> -			qcom,ports-hstop =		/bits/ 8 <0xff 0xff 0xff 0xff>;
> -			qcom,ports-word-length =	/bits/ 8 <0xff 0xff 0xff 0xff>;
> -			qcom,ports-block-pack-mode =	/bits/ 8 <0xff 0xff 0xff 0xff>;
> -			qcom,ports-block-group-count =	/bits/ 8 <0xff 0xff 0xff 0xff>;
> -			qcom,ports-lane-control =	/bits/ 8 <0x01 0x02 0x00 0x00>;
> +			qcom,dout-ports = <1>;
> +
> +			qcom,ports-sinterval-low =	/bits/ 8 <0x00 0x01 0x01 0x03 0x03>;

[Severity: High]
Does prepending an element to the qcom,ports-* arrays in swr2 shift the
absolute index mapping expected by the TX codec's qcom,tx-port-mapping?

The soundwire driver maps these array elements sequentially to pconfig[1]
through pconfig[nports]. Slave devices, such as the WCD9395 TX codec, rely
on absolute Master Port indices defined in their board-level tx-port-mapping
properties to directly index pconfig and program fixed hardware registers.

By prepending a new element to account for dout-ports = 1, it appears all
subsequent configurations are shifted. As a result, pconfig[2] might now
receive data from array index 0 instead of index 1 (for example, lane_control
would change from 0x02 to 0x01).

Will this misconfigure the active TX SoundWire ports and break capture audio
functionality on SM8650 boards?

> +			qcom,ports-offset1 =		/bits/ 8 <0x00 0x00 0x00 0x01 0x01>;
> +			qcom,ports-offset2 =		/bits/ 8 <0x00 0x00 0x00 0x00 0x00>;
> +			qcom,ports-hstart =		/bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
> +			qcom,ports-hstop =		/bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
> +			qcom,ports-word-length =	/bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
> +			qcom,ports-block-pack-mode =	/bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
> +			qcom,ports-block-group-count =	/bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
> +			qcom,ports-lane-control =	/bits/ 8 <0xff 0x01 0x02 0x00 0x00>;
>  
>  			#address-cells = <2>;
>  			#size-cells = <0>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-sm8650-upstream-cpu-props-v3-0-eeb6e9fa7581@linaro.org?part=3