Re: [PATCH v3 15/17] arm64: dts: imx952-evk: Add board muxes to select between CAN1/PDM

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but repeated probe deferrals of devices consuming `pinctrl-multiplexer` states will cause a memory leak in the `pinctrl-generic-mux` driver.
--

--- Patch [15]: [PATCH v3 15/17] arm64: dts: imx952-evk: Add board muxes to select between CAN1/PDM ---
commit 8303ed37e9ec3be6828aa6ff3d2b548e65c73826
Author: Chancel Liu <chancel.liu@nxp.com>

arm64: dts: imx952-evk: Add board muxes to select between CAN1/PDM

This commit replaces static gpio-hog settings with GPIO-controlled board
muxes. It uses the pinctrl-multiplexer framework so that conflicting
functions between CAN1 and PDM can be selected at runtime.

> diff --git a/arch/arm64/boot/dts/freescale/imx952-evk.dts b/arch/arm64/boot/dts/freescale/imx952-evk.dts
> index 2224b90aafe93..e9d735dc2a51b 100644
> --- a/arch/arm64/boot/dts/freescale/imx952-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx952-evk.dts
> @@ -52,6 +52,40 @@ chosen {
>  		stdout-path = &lpuart1;
>  	};
>  
> +	can1_pdm_mux: mux-controller-0 {
> +		compatible = "gpio-mux";
> +		#mux-control-cells = <0>;
> +		#mux-state-cells = <1>;
> +		mux-gpios = <&pcal6416 10 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	mqs1_en_mux: mux-controller-1 {
> +		compatible = "gpio-mux";
> +		#mux-control-cells = <0>;
> +		#mux-state-cells = <1>;
> +		mux-gpios = <&pcal6416 15 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	pinctrl-gpiomux {
> +		compatible = "pinctrl-multiplexer";

[Severity: High]
This isn't a bug introduced by this patch, but adding this multiplexer 
reveals a pre-existing memory leak in the pinctrl-generic-mux driver.

When a consumer device (e.g., flexcan1) probes, the pinctrl core calls
mux_pinmux_dt_node_to_map() in drivers/pinctrl/pinctrl-generic-mux.c. That
function unconditionally allocates memory using devm_ APIs attached to the
provider's device:

drivers/pinctrl/pinctrl-generic-mux.c:mux_pinmux_dt_node_to_map() {
	...
	function = devm_kzalloc(pctldev->dev, sizeof(*function), GFP_KERNEL);
	if (!function)
		return -ENOMEM;

	group_names = devm_kcalloc(pctldev->dev, 1, sizeof(*group_names), GFP_KERNEL);
	...
}

If the consumer defers probe, these allocations are orphaned on the
provider's devres list and aren't freed during the consumer's cleanup
path. On subsequent probe attempts, new allocations are made, leaking
memory each time.

Is there a plan to fix this in drivers/pinctrl/pinctrl-generic-mux.c so
that repeated probe deferrals don't cause unbounded memory exhaustion on
the provider device?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260824022020.2812810-1-chancel.liu@oss.nxp.com?part=15