Re: [PATCH v4 2/2] arm64: dts: ti: Add audio overlay for k3-j721s2-evm

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The audio device tree overlay fails to disable conflicting CAN node devices from the base board, causing McASP audio signal routing to be silently broken when CAN interfaces are brought up.
--

commit c1ba2c3319437f9663a75e0a335a9f4615ec2ea6
Author: Jayesh Choudhary <j-choudhary@ti.com>

arm64: dts: ti: Add audio overlay for k3-j721s2-evm

Add device tree overlay to enable analog audio support on J721S2-EVM
using PCM3168A codec connected to McASP4 serializers.

> diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
> new file mode 100644
> index 0000000000000..6ed4d6fc414d9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
[ ... ]
> +&mux0 {
> +	idle-state = <0>;
> +};
> +
> +&mux1 {
> +	idle-state = <0>;
> +};

Will this signal routing be silently broken if the CAN interfaces are brought
up?

The base board device tree (k3-j721s2-common-proc-board.dts) enables
main_mcan3 and main_mcan5, which use PHYs configured with mux-states = <&mux0 1>
and <&mux1 1>. The McASP node here does not claim the mux via the mux-control
API, relying entirely on the idle-state fallback.

When the CAN interfaces are brought up (e.g., ifconfig can3 up), the CAN PHY
driver will call mux_state_select(), actively driving the mux controllers to
state 1. This overrides the idle-state 0 required for audio, physically breaking
the McASP signal routing without the audio driver's knowledge.

Should the overlay explicitly disable main_mcan3 and main_mcan5 to prevent this
hardware conflict?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519142341.2531948-1-m-shah@ti.com?part=2