From: "Bjørn Mork" <bjorn@mork.no>
To: viresh kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
"cpufreq\@vger.kernel.org" <cpufreq@vger.kernel.org>,
"linux-pm\@vger.kernel.org" <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH Resend] cpufreq: remove sysfs files for CPU which failed to come back after resume
Date: Mon, 23 Dec 2013 10:23:04 +0100 [thread overview]
Message-ID: <877gavgbuv.fsf@nemi.mork.no> (raw)
In-Reply-To: <52B7EC81.6060202@linaro.org> (viresh kumar's message of "Mon, 23 Dec 2013 13:25:45 +0530")
viresh kumar <viresh.kumar@linaro.org> writes:
> On Monday 23 December 2013 12:25 PM, Bjørn Mork wrote:
>> That's correct. The immediate result of the failure is exactly the
>> same.
>
> Okay..
>
>> The difference is that a subsequent resume would restore the cpufreq
>> device whether it existed or not. That made a complete suspend/resume
>> fix up any missing cpufreq device, e.g. one that was removed by a
>> previous error.
>
> I see.. Please see if below patch fixes it for you, it should :)
Confirmed. With that patch on top of the current pm-cpufreq branch all
functionality is restored and there are no regressions AFAICS.
I still don't understand why you want to add this hackish half-assed
suspend implementation, but at least it doesn't seem to break anything
anymore. But if you really want to implement suspend/resume, then you
do need to keep the whole device and not just the sysfs files. Keeping
the attribute files allow you to save and restore changed permissions,
but it doesn't save any user modified settings. What's the point of
that? Is the next step yet another hack to save those? Where does this
end?
Why not implement proper support for suspending the "cpufreq device",
and *then* enable suspend/resume support?
Well, not my problem... Just wondering really.
Bjørn
next prev parent reply other threads:[~2013-12-23 9:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-20 15:56 [PATCH Resend] cpufreq: remove sysfs files for CPU which failed to come back after resume Viresh Kumar
2013-12-22 1:00 ` Rafael J. Wysocki
2013-12-23 5:55 ` Bjørn Mork
2013-12-23 6:02 ` Viresh Kumar
2013-12-23 6:55 ` Bjørn Mork
2013-12-23 7:55 ` viresh kumar
2013-12-23 9:23 ` Bjørn Mork [this message]
2013-12-23 10:45 ` Viresh Kumar
2013-12-23 10:57 ` Bjørn Mork
2013-12-23 11:13 ` Viresh Kumar
2013-12-23 11:42 ` Bjørn Mork
2013-12-23 15:45 ` viresh kumar
2013-12-24 0:35 ` Rafael J. Wysocki
2013-12-24 0:27 ` Viresh Kumar
2013-12-24 0:43 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877gavgbuv.fsf@nemi.mork.no \
--to=bjorn@mork.no \
--cc=cpufreq@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox