Re: [PATCH] clk: raspberrypi: Handle cpufreq device registration failure

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] clk: raspberrypi: core clock probe fails if optional cpufreq device fails
--

commit 9a3a7cc11a038dd3ae191483f044c2febc6c2ed1
Author: Triet Hoang <triet.hoang.dev@gmail.com>
clk: raspberrypi: Handle cpufreq device registration failure

This commit adds an error check when registering the raspberrypi-cpufreq 
device in the clock driver probe function. It propagates the error if the 
cpufreq device fails to register, preventing a successful probe return.

> diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
> index f1a99de6de4f1..9882f243d6813 100644
> --- a/drivers/clk/bcm/clk-raspberrypi.c
> +++ b/drivers/clk/bcm/clk-raspberrypi.c
> @@ -553,6 +553,8 @@ static int raspberrypi_clk_probe(struct platform_device *pdev)
>  
>  	rpi->cpufreq = platform_device_register_data(dev, "raspberrypi-cpufreq",
>  						     -1, NULL, 0);
> +	if (IS_ERR(rpi->cpufreq))
> +		return PTR_ERR(rpi->cpufreq);

[Severity: Medium]
Does this introduce a regression where fundamental core clocks might be
unregistered if the optional cpufreq device fails?

The raspberrypi-clk driver provides essential system clocks, such as arm,
core, and pixel. By returning an error from raspberrypi_clk_probe(), devres
will automatically unregister these clocks. This can prevent other fundamental
SoC devices that depend on these clocks from probing, which could severely
degrade the system or prevent it from booting entirely.

Is it safe to structurally tie the survival of the core clocks to an optional
dynamic frequency scaling child device?

>  
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918044131.608482-1-triet.hoang.dev@gmail.com?part=1