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/14/2013 07:31 PM, Jarzmik, Robert wrote:
> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@sisk.pl] 
> Sent: Tuesday, May 14, 2013 2:59 PM
> To: Jarzmik, Robert
> Cc: R, Durgadoss; Srivatsa S. Bhat; Viresh Kumar; linux-pm@vger.kernel.org; Greg Kroah-Hartman
> Subject: Re: S3, SMP non boot cpus and /sys/devices/system/cpu[1-9]/cpufreq/scaling_max_freq
> 
[...]
>> One can argue that we're doing too much during system suspend, because what we really need is the _cpu_down() down the road.  That said we need to let cpufreq (and other subsystems too) know that this CPU is gone temporarily and it is good to have a clean state in case it doesn't come up later.
> Agreed.
> 
>> So I think that the cleanest way to address this issue would be to rearrange the code so that the sysfs is not modified by suspend/resume at all, unless the resume fails, but I don't think it's going to be easy to make that happen.
> I think I miss the point in there, as a failing resume path
> should be catchable in the cpufreq framework. Well,
> I should have a closer look in here.
> 

Please take a look at the v2 of the patch that I sent out
just now. IMHO it addresses Rafael's concern adequately.

Regards,
Srivatsa S. Bhat