Re: [PATCH v2 7/9] ARM: dts: ux500: Convert HREF audio to audio-graph-card2

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] sound: ux500: hardcoded TDM slots break dynamic channel support
- [High] sound: ux500: ABI regression causing loss of DAPM pin switches
--

commit 3bce354bbefb3531701f651af445996e9f8ba398
Author: Linus Walleij <linusw@kernel.org>

ARM: dts: ux500: Convert HREF audio to audio-graph-card2

This commit converts the HREF500 and HREF520 sound hardware to use
audio-graph-card2 in their device trees, replacing the legacy machine driver.
It establishes links between MSP1/MSP3 and the audio codec, along with
defining the TDM frame properties and endpoints.

> diff --git a/arch/arm/boot/dts/st/ste-href-ab8500.dtsi b/arch/arm/boot/dts/st/ste-href-ab8500.dtsi
> index 5eeb44c5e9323..ff72f5f6d6525 100644
> --- a/arch/arm/boot/dts/st/ste-href-ab8500.dtsi
> +++ b/arch/arm/boot/dts/st/ste-href-ab8500.dtsi
> @@ -6,6 +6,48 @@
>  #include "ste-ab8500.dtsi"
>  
>  / {
> +	href_sound: sound {
> +		compatible = "audio-graph-card2";
[Severity: High]
Does this transition to audio-graph-card2 omit the creation of DAPM pin
switches that were explicitly created by the legacy machine driver?

The audio-graph-card2 driver fundamentally lacks support for generating these
switches because it does not parse a 'pin-switches' DT property (unlike
simple-audio-card), nor are they specified in the DT.

Could this lead to the loss of 20 userspace ALSA mixer controls (such as
'Headset Left Switch' and 'Mic 1 Switch'), breaking ALSA UCM profiles,
PulseAudio, and scripts that attempt to route audio or toggle endpoints?

> +		label = "HREF-500";
> +		widgets =

[ ... ]

> +&codec {
> +	assigned-clocks = <&ab8500_clock AB8500_SYSCLK_INT>;
> +	assigned-clock-parents = <&ab8500_clock AB8500_SYSCLK_ULP>;
> +
> +	ports {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		port@0 {
> +			reg = <0>;
> +
> +			href_codec_playback: endpoint {
> +				remote-endpoint = <&href_msp1_endpoint>;
> +				bitclock-master;
> +				frame-master;
> +				dai-tdm-slot-num = <16>;
> +				dai-tdm-slot-width = <16>;
> +				dai-tdm-slot-tx-mask = <0 1 0 1>;
[Severity: High]
Can statically setting dai-tdm-slot-tx-mask limit playback to exactly 2
channels (bits 1 and 3), permanently forcing stereo playback and breaking
previously supported mono playback?

Looking at ux500_msp_dai_hw_params(), the backend CPU DAI driver rigidly
enforces that the runtime ALSA channel count matches the active slots defined
statically in the DT:

sound/soc/ux500/ux500_msp_dai.c:ux500_msp_dai_hw_params() {
    ...
    if (!slots_active || params_channels(params) != slots_active)
        return -EINVAL;
    ...
}

Will userspace audio applications playing mono or capturing stereo directly via
hw: fail with -EINVAL, causing a functional regression from the legacy machine
driver?

> +			};
> +		};
> +
> +		port@1 {
> +			reg = <1>;
> +
> +			href_codec_capture: endpoint {
> +				remote-endpoint = <&href_msp3_endpoint>;
> +				bitclock-master;
> +				frame-master;
> +				dai-tdm-slot-num = <16>;
> +				dai-tdm-slot-width = <16>;
> +				dai-tdm-slot-rx-mask = <1>;
> +			};
> +		};
> +	};
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918-ux500-simple-sound-v2-0-88d29416e3c3@kernel.org?part=7