Re: [PATCH Resend] cpufreq: remove sysfs files for CPU which failedto come back after resume

[Viresh Kumar]

On 23 December 2013 16:27, Bjørn Mork <bjorn@xxxxxxx> wrote:
> I could be missing something, but I haven't noticed any attempt to
> preserve anything except the sysfs files.

What do you mean by sysfs here? Doesn't the below files mentioned
by you also come in sysfs?

> I tried modifying the max frequency, using
>
>  echo 800000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
>  echo 800000 >/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
>
> After supend + resume the boot CPU still had the modifed maximum, while
> the non-boot core was reset to the default value.

This is all we were doing. i.e. not removing or putting the kobject which has
all these files and so shouldn't get reallocated at all..

So, has resumed passed on the first go only? As it was failing for the first
time in your case and hence this thread. In that case we are going to get
new files and so all values will be restored to default values.

Otherwise I don't see why we should loose any values here..

>  I changed the gid of
> both files too, verifying that they were saved and restored as expected.
> But the value will change to default.

For both boot and non-boot CPUs? I am asking because things should
be very plain for boot CPU atleast as that is never hot unplugged..

Have you tested this with the latest patches I gave?

> IMHO it would still be a lot better if this was handled as a true
> hotplug event, allowing userspace to reset values/modes/owners on
> resume. Hiding the hotplug event and saving part of the userspace
> controlled environment is worse than not doing anything at all.

We should be saving everything correctly with the current code,
with the patches I have sent.. And so things should work as far
as I can comment.

If you can confirm that these happened despite of latest patches
then probably I need to test that again on my thinkpad. But I was
quite sure this worked :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/