Re: [PATCH v4 0/4] cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload
Christian Loehle <[email protected]>
| Newsgroups | org.kernel.vger.linux-pm,dev.linux.lists.acpica-devel,org.kernel.vger.linux-acpi,org.kernel.vger.linux-kernel,org.kernel.vger.linux-tegra |
|---|---|
| Message-ID | <[email protected]> |
On 8/25/26 22:20, Sumit Gupta wrote: > > On 07/08/26 01:38, Sumit Gupta wrote: >> This series keeps the CPPC cpufreq policy alive across CPU hotplug and >> preserves the OSPM-set CPPC registers (Energy Performance Preference, >> Autonomous Activity Window, Autonomous Selection - set via sysfs). >> >> Without online()/offline() callbacks, the core tears a policy down when >> its last CPU goes offline and rebuilds it on the way back, re-reading the >> CPPC capabilities each time. The values written to these registers can >> be lost: >> >> - Across CPU hotplug or suspend/resume: the platform may reset them >> while the CPU is offline. >> - On driver unload: the driver-written value is left in the register >> instead of returning to its pre-driver state. >> >> Handle these with: >> >> - Patch 1: adds online()/offline() callbacks so the core keeps policy >> alive across CPU hotplug instead of tearing it down and rebuilding it. >> - Patch 2: makes the autonomous selection register helpers take a u64. >> - Patch 3: adds a table-driven mechanism that captures each register's >> firmware value at init(), restores it from offline(), and reapplies >> the OSPM-set value from online(). >> - Patch 4: extends the same save/restore to system suspend/resume. > > Gentle reminder. > Could this be considered for queuing if nothing further needs addressing. FWIW both sashiko findings look legit to me, the feedback counters one I wouldn't consider that drastic, given that these counters are expected to have 'fuzzy' readings anyhow, the second one is worse (losing sysfs settings on cpu_online())