Re: S3, SMP non boot cpus and /sys/devices/system/cpu[1-9]/cpufreq/scaling_max_freq

["Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>]

On 05/15/2013 11:46 AM, Viresh Kumar wrote:
> On 14 May 2013 19:24, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>> From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>> Subject: [PATCH v2] cpufreq: Preserve sysfs file permissions across suspend/resume
>>
>> The file permissions of cpufreq per-cpu sysfs files are not preserved across
>> suspend/resume because we internally go through the CPU Hotplug path which
>> reinitializes the file permissions on CPU online.
>>
>> But the user is not supposed to know that we are using CPU hotplug
>> internally within suspend/resume (IOW, the kernel should not silently wreck
>> the user-set file permissions across a suspend cycle). Therefore, we need to
>> preserve the file permissions as it is, across suspend/resume.
>>
>> The simplest way to achieve that is to just not touch the sysfs files at
>> all - ie., just ignore the CPU hotplug events in the suspend/resume path
>> (_FROZEN) in the cpufreq hotplug callback.
>>
>> Reported-by: Robert Jarzmik <robert.jarzmik@intel.com>
>> Reported-by: Durgadoss R <durgadoss.r@intel.com>
>> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>> ---
>> v2: Use UP_CANCELED_FROZEN notification to delete the sysfs files if the
>> CPUs don't come up during resume.
> 
> Is it also possible that more cpus come up after resume? i.e. we had 2 cpus
> at suspend and 3 at resume?

Nope. That's not possible. While suspending we note down the online non-boot
CPUs we have, in a cpumask, and take them offline. On resume, we try to online
the CPUs in that cpumask. So there is no chance for more CPUs to come up during
resume.

> 
>>  drivers/cpufreq/cpufreq.c       |    4 +---
>>  drivers/cpufreq/cpufreq_stats.c |    7 ++++---
>>  2 files changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 1b8a48e..284ba63 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1832,15 +1832,13 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb,
>>         if (dev) {
>>                 switch (action) {
>>                 case CPU_ONLINE: 
>> -               case CPU_ONLINE_FROZEN:
>>                         cpufreq_add_dev(dev, NULL);
>>                         break;
>>                 case CPU_DOWN_PREPARE:
>> -               case CPU_DOWN_PREPARE_FROZEN:
>> +               case CPU_UP_CANCELED_FROZEN:
>>                         __cpufreq_remove_dev(dev, NULL);
>>                         break;
>>                 case CPU_DOWN_FAILED:
>> -               case CPU_DOWN_FAILED_FROZEN:
>>                         cpufreq_add_dev(dev, NULL);
>>                         break;
> 
> I have forgotten meaning of these flags now :(

Take a quick peek at kernel/cpu.c and include/linux/cpu.h and all those
memories will come rushing back ;-)

> So, CPU_ONLINE, CPU_DOWN_PREPARE and CPU_DOWN_FAILED
> are called when cpus are added/removed (but not for cpu_down in suspend
> resume)? and _FROZEN ones are only used for s2r/s2d?
> 

Yes, that's right. For the suspend/resume and hibernate/restore case, all
the notifiers use the _FROZEN flags. The regular hotplug notifications use
the flags without the _FROZEN suffix.

Regards,
Srivatsa S. Bhat