Re: [PATCH RESEND v6 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 2 potential issue(s) to consider:

New issues:
- [Medium] The commit message claims to 'Add GPIO hogs to route I2C3 lines and McASP serializers', but I2C3 routing is implemented using a dynamically managed gpio-mux (mux-controller) rather than a static GPIO hog.

Pre-existing issues:
- [High] Adding the `mux-states` property to the `main_i2c3` node triggers a preexisting bug in the `i2c-omap` driver where the multiplexer control state is deselected twice on driver unbind, corrupting the multiplexer's semaphore lock.
--

--- Patch [2]: [PATCH RESEND v6 2/2] arm64: dts: ti: Add audio overlay for k3-j721s2-evm ---
commit b8739eb8a1b6fedb5e3ae2312559bc8686123be2
Author: Jayesh Choudhary <j-choudhary@ti.com>

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

This patch adds a device tree overlay to enable analog audio support on the
J721S2-EVM. It configures the sound-card, audio codec, I2C3, and McASP4
along with their respective pinmux and signal routing settings.

> - Add GPIO hogs to route I2C3 lines and McASP serializers

[Severity: Medium]
Is this commit message description accurate for the I2C3 routing?

Looking at the added overlay, I2C3 routing is implemented using a
dynamically managed gpio-mux (mux-controller-2) rather than a static
GPIO hog.

> 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
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
[ ... ]
> +&main_i2c3 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&main_i2c3_pins_default>;
> +	clock-frequency = <400000>;
> +	mux-states = <&i2c_mux 1>;

[Severity: High]
This is a pre-existing issue, but adding this property exposes a latent
double-deselect bug in the i2c-omap driver during unbind.

The devm_mux_state_get_optional_selected() API registers a devres action
that automatically calls mux_state_deselect(). However, the unbind path
explicitly calls it again:

drivers/i2c/busses/i2c-omap.c:omap_i2c_remove() {
	...
	if (omap->mux_state)
		mux_state_deselect(omap->mux_state);
	...
}

Because mux_control_deselect() unconditionally executes up(&mux->lock),
would this double deselect increment the binary semaphore past 1 and
break mutual exclusion for the multiplexer?

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