Re: [PATCH RFC 05/10] PM / devfreq: Add new track_remote flag for governors

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Skipping `profile->target()` for `TRACK_REMOTE` bypasses OPP frequency rounding, causing state desynchronization and permanently failing `devfreq_update_status()` on QoS-clamped frequencies.
--

--- Patch [5]: [PATCH RFC 05/10] PM / devfreq: Add new track_remote flag for governors ---
commit 3b4a905187566fcb4b261840b1355a57916fec6b
Author: Sibi Sankar <sibi.sankar@oss.qualcomm.com>

PM / devfreq: Add new track_remote flag for governors

Some devfreq governors need to track frequency changes performed on remote
devices rather than driving the frequency updates themselves. Add a new
DEVFREQ_GOV_FLAG_TRACK_REMOTE governor flag to skip the local target() call
and just keep its transition statistics and notifiers in sync.

> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 2f27a239e34a6..71c6ced9e4e1d 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -348,6 +348,26 @@ static int devfreq_set_target(struct devfreq *devfreq, unsigned long new_freq,
>  	unsigned long cur_freq;
>  	int err = 0;
>  
> +	/*
> +	 * When a remote agent (e.g. firmware) owns the frequency, skip the
> +	 * local profile->target() call. Still emit the PRECHANGE/POSTCHANGE
> +	 * pair and the trace event so that transition-notifier subscribers
> +	 * (passive governor, devfreq cooling, etc.) and tracing observe the
> +	 * frequency change exactly as they would on the normal path.
> +	 */
> +	if (devfreq->governor &&
> +	    IS_SUPPORTED_FLAG(devfreq->governor->flags, TRACK_REMOTE)) {
> +		freqs.old = devfreq->previous_freq;
> +		freqs.new = new_freq;
> +		devfreq_notify_transition(devfreq, &freqs, DEVFREQ_PRECHANGE);
> +
> +		if (trace_devfreq_frequency_enabled() && new_freq != freqs.old)
> +			trace_devfreq_frequency(devfreq, new_freq, freqs.old);
> +
> +		devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
> +		goto update_status;

[Severity: High]
Does skipping profile->target() here cause issues with unrounded frequencies?

When a frequency update occurs, devfreq_update_target() can clamp the
requested frequency to a PM QoS limit (e.g., min_freq) that might not be an
exact valid OPP frequency.

By skipping profile->target() (which normally rounds the frequency to a valid
OPP), this unrounded frequency is passed directly to devfreq_update_status()
via the goto.

Inside devfreq_update_status(), devfreq_get_freq_level() requires an exact
match in the freq_table. If the unrounded frequency is not found, it fails
and returns < 0, preventing stats updates and leaving previous_freq as an
invalid OPP.

> +	}
> +
>  	if (devfreq->profile->get_cur_freq)
>  		devfreq->profile->get_cur_freq(devfreq->dev.parent, &cur_freq);
>  	else

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724-rfc_v8_scmi_memlat-v1-0-cb732bcff1f4@oss.qualcomm.com?part=5