Re: [PATCH v3 09/17] arm64: dts: imx943-evk: Add board muxes to select between CAN1/PDM and MQS1/MIC

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Repeated deferred probing of the `micfil` consumer causes severe devres memory and reference leaks in the `pinctrl-generic-mux` provider.
--

--- Patch [9]: [PATCH v3 09/17] arm64: dts: imx943-evk: Add board muxes to select between CAN1/PDM and MQS1/MIC ---
commit 77c9c6202b63305da0b9143118c00d14c3943f7f
Author: Chancel Liu <chancel.liu@nxp.com>

arm64: dts: imx943-evk: Add board muxes to select between CAN1/PDM and MQS1/MIC

This commit replaces static gpio-hogs with GPIO-controlled board muxes
using the pinctrl-multiplexer framework. It allows runtime selection between
conflicting functions (CAN1/PDM and MQS1/MICFIL) and updates the MICFIL node
to use this new pinctrl selection.

> diff --git a/arch/arm64/boot/dts/freescale/imx943-evk.dts b/arch/arm64/boot/dts/freescale/imx943-evk.dts
> index 64660f94f4e9c..07b782ef698ad 100644
> --- a/arch/arm64/boot/dts/freescale/imx943-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx943-evk.dts

[ ... ]

> @@ -710,7 +731,7 @@ &micfil {
>  	assigned-clock-rates = <3932160000>,
>  			       <3612672000>, <393216000>,
>  			       <361267200>, <49152000>;
> -	pinctrl-0 = <&pinctrl_pdm>;
> +	pinctrl-0 = <&pinctrl_pdm>, <&mic_fun>, <&pdm_fun>;

[Severity: High]
This is a pre-existing issue in the pinctrl-multiplexer driver, but routing
the micfil node to use this provider actively triggers it. Can this lead to
severe devres memory and reference leaks if the micfil consumer defers probe?

Looking at mux_pinmux_dt_node_to_map() in
drivers/pinctrl/pinctrl-generic-mux.c, resources are allocated against the
provider's device (pctldev->dev):

	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 (!group_names)
		return -ENOMEM;

	function->mux_state = devm_mux_state_get_from_np(pctldev->dev, NULL, np_config);

When the micfil device defers probe after obtaining pinctrl handles (or is
unbound and rebound), the pinctrl core frees the consumer's maps. However,
these allocations remain on the provider device's devres list.

On the next probe attempt, mux_pinmux_dt_node_to_map() allocates new
structures and calls pinmux_generic_add_function(). Since the function name
already exists in the radix tree from the previous attempt, the pinctrl
core returns the old selector. 

The newly allocated objects and the mux_chip reference acquired by
devm_mux_state_get_from_np() are abandoned on the provider's list. This
compounds the leak on every deferral and prevents the mux_chip from ever
being freed.

Should the pinctrl-generic-mux driver be fixed to tie these allocations to
the map lifecycle before we expose this path via the DTS change?

>  	pinctrl-names = "default";
>  	status = "okay";
>  };

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