Re: [外部邮件] Re: [PATCH v4 2/2] cpufreq: acpi-cpufreq: fix P-state index mismatch in get_cur_freq_on_cpu()

[Rafael J. Wysocki (Intel)]

On Tue, Sep 15, 2026 at 7:04 AM Li,Rongqing <lirongqing@xxxxxxxxx> wrote:
>
>
>
> eq: acpi-cpufreq: fix P-state index
> > mismatch in get_cur_freq_on_cpu()
> >
> > On Thu, Sep 10, 2026 at 1:13 PM lirongqing <lirongqing@xxxxxxxxx> wrote:
> > >
> > > From: Li RongQing <lirongqing@xxxxxxxxx>
> > >
> > > get_cur_freq_on_cpu() uses perf->state, which is an index into
> > > perf->states[], to index policy->freq_table[]. However, freq_table[]
> > > is built by filtering _PSS entries that are not lower in frequency
> > > than the previous one, so its index space no longer matches
> > > perf->states[]. The original P-state index for each remaining
> > > freq_table entry is stored in driver_data.
> > >
> > > Once an entry has been skipped, using perf->state as an index into
> > > freq_table[] can therefore select the frequency of a different
> > > P-state.
> > >
> > > The reported current frequency itself remains correct because it is
> > > obtained from extract_freq(). The mismatch only affects the cached
> > > frequency used by get_cur_freq_on_cpu() to detect a firmware frequency
> > > change behind our back.
> > >
> > > If the wrong table entry contains a frequency different from the one
> > > the CPU is actually running at, the check falsely detects a frequency
> > > change and sets data->resume. The next ->target() call then performs a
> > > redundant control-register write even if the requested P-state is
> > > already the current P-state.
> > >
> > > Conversely, if the wrong table entry happens to contain the frequency
> > > to which firmware has changed the CPU, the frequency change is missed
> > > and data->resume remains clear. A subsequent ->target() call for the
> > > P-state that the cpufreq core believes to be current can then
> > > short-circuit without rewriting the control register, leaving the CPU
> > > at the firmware-selected frequency until a different P-state is
> > > requested.
> > >
> > > Fix this by taking the cached frequency directly from
> > > perf->states[perf->state].core_frequency. perf->state and states[] use
> > > perf->the same P-state index space, and converting
> > > core_frequency to kHz yields the same value stored in the
> > > corresponding freq_table entry during initialization.
> >
> > Sashiko has comments on this patch and it has a point IMV:
> >
> > https://sashiko.dev/#/patchset/20260910111329.2220-1-lirongqing%40baid
> > u.com
> >
>
> The extract_msr() fallback issue should be valid , but it is a pre-existing problem that is
> orthogonal to the index mismatch fixed by this series. I would therefore prefer to keep this series scoped to that mismatch.
>
> If there is no interest in addressing it here, I will send a separate patch to fix it.

However, according to Sashiko (and if I understand its report
correctly) that problem interferes with the logic in the patch and may
render it ineffective in some cases.  Isn't that correct?