Re: [PATCH v2 2/2] PM / devfreq: add Airoha SoC Subsystem devfreq driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] devfreq: target callback fails to update *freq to actual applied rate
--

commit ef9292d19d56ca62518a03cc0a714b29d6101475
Author: Christian Marangi <ansuelsmth@gmail.com>

PM / devfreq: add Airoha SoC Subsystem devfreq driver

Add simple Airoha SoC devfreq driver. This simple driver register a
driver from a given clock and register a passive governor to scale the
frequency with the CPU frequency.

> diff --git a/drivers/devfreq/airoha-subsystem-devfreq.c b/drivers/devfreq/airoha-subsystem-devfreq.c
> new file mode 100644
> index 0000000000000..4b89121f7b8ec
> --- /dev/null
> +++ b/drivers/devfreq/airoha-subsystem-devfreq.c
[ ... ]
> +static int airoha_devfreq_target(struct device *dev, unsigned long *freq,
> +				 u32 flags)
> +{
> +	struct airoha_devfreq_data *data = dev_get_drvdata(dev);
> +
> +	return clk_set_rate(data->clk, *freq);
> +}

[Severity: Medium]
Does this target callback need to update the freq pointer to the actual
frequency applied?

When the devfreq core or governor requests a frequency transition, it calls
the .target callback with the requested frequency in the freq parameter. This
happens on every frequency transition triggered by the governor.

The devfreq core's internal state (devfreq->previous_freq) and statistics
track the frequency returned in the freq pointer. If the unrounded or
interpolated requested frequency is blindly passed to clk_set_rate() and
left unchanged instead of being updated to the actual frequency applied to
the hardware, this can cause -EINVAL lookup errors in devfreq_get_freq_level()
and break statistics.

Could devfreq_recommended_opp() be used here to constrain the requested
frequency to a valid OPP and update freq before applying it?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009073330.18175-1-ansuelsmth@gmail.com?part=2