Re: [PATCH v4 2/3] mux: convert to use fwnode interface

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] pinctrl: memory leak in dt_node_to_map on probe deferral
--

commit a66771846f5e6a77740838d742398ffebadf6b60
Author: Fabio Forni <development@redaril.me>

mux: convert to use fwnode interface

This commit converts the mux subsystem to use the fwnode interface
instead of device nodes, as firmware node is a more common abstraction.

> diff --git a/drivers/pinctrl/pinctrl-generic-mux.c b/drivers/pinctrl/pinctrl-generic-mux.c
> index 202b72351efb7..6d5b6100c5ca2 100644
> --- a/drivers/pinctrl/pinctrl-generic-mux.c
> +++ b/drivers/pinctrl/pinctrl-generic-mux.c
[ ... ]
> @@ -50,7 +50,9 @@ mux_pinmux_dt_node_to_map(struct pinctrl_dev *pctldev,
>  	if (!group_names)
>  		return -ENOMEM;
>  
> -	function->mux_state = devm_mux_state_get_from_np(pctldev->dev, NULL, np_config);
> +	function->mux_state = devm_mux_state_get_from_fwnode(pctldev->dev,
> +							     NULL,
> +							     of_fwnode_handle(np_config));

[Severity: Medium]
Will this leak memory if the consumer device defers probing?

The mux_pinmux_dt_node_to_map() function is called by the pinctrl core each
time a consumer parses its DT mappings. It allocates devm resources explicitly
bound to pctldev->dev (the pinctrl provider device), including the mux_state
allocated here, as well as the function and group_names allocated earlier in
the same function:

	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;

If the consumer device's probe later returns -EPROBE_DEFER, the consumer's
pinctrl mappings are freed, but these devm allocations remain permanently bound
to the provider device. 

When the consumer reprobes, it triggers this function again, returning the
existing selector from pinmux_generic_add_function() and completely leaking
the newly allocated devm resources on the provider's devres list. Repeated
probe deferrals can cause an unbounded memory leak.

Should these allocations be tied to the consumer device instead, or explicitly
freed when the map is released?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008-mux_fwnode-v4-0-ba3330e44b2a@redaril.me?part=2