Re: [PATCH] clk: s2mps11: Propagate OF provider registration failures

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] of_clk_add_hw_provider() unconditionally marks fwnode as initialized on failure.
--

commit 70cc7ee16e2987b440f1878c683c89d530c69a34
Author: Pengpeng Hou <hppiscas@163.com>

clk: s2mps11: Propagate OF provider registration failures

This commit updates s2mps11_clk_probe() to correctly check the return value
of of_clk_add_hw_provider() and propagate registration failures. It also
adjusts the cleanup path to handle omitted clocks.

> diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
> index fa5ac8f673f6e..94969d97d6e99 100644
> --- a/drivers/clk/clk-s2mps11.c
> +++ b/drivers/clk/clk-s2mps11.c
[ ... ]
> @@ -192,8 +192,10 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
>  		clk_data->hws[i] = &s2mps11_clks[i].hw;
>  	}
>  
> -	of_clk_add_hw_provider(s2mps11_clks->clk_np, of_clk_hw_onecell_get,
> -			       clk_data);
> +	ret = of_clk_add_hw_provider(s2mps11_clks->clk_np,
> +				     of_clk_hw_onecell_get, clk_data);
> +	if (ret)
> +		goto err_reg;

[Severity: High]
This is a pre-existing issue, but by properly propagating the error from
of_clk_add_hw_provider(), could this cause dependent consumers to fail their
probe instead of deferring?

Looking at of_clk_add_hw_provider() in drivers/clk/clk.c, if it fails, it
unconditionally marks the fwnode as initialized before returning the error:

drivers/clk/clk.c:of_clk_add_hw_provider() {
    ...
	ret = of_clk_set_defaults(np, true);
	if (ret < 0)
		of_clk_del_provider(np);

	fwnode_dev_initialized(&np->fwnode, true);

	return ret;
}

If of_clk_set_defaults() fails (e.g., returning -EPROBE_DEFER),
of_clk_del_provider() unregisters the provider and correctly marks the fwnode
uninitialized, but it is then unconditionally forced to true.

Since fw_devlink relies on this initialized state, does this trick consumers
into thinking the supplier is ready, thereby breaking the EPROBE_DEFER
mechanism for dependent devices when this failure path is taken?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260906033651.84082-1-hppiscas@163.com?part=1