linux-kernel - Re: [PATCH 0/2] Add exit_prepare callback to the cpufreq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOh2x=n57WVOAMBsM_nPYOjjMsvWf5WB8RptoyCC63y8iab3Kg@mail.gmail.com>
Date:	Tue, 18 Mar 2014 10:36:12 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Dirk Brandewie <dirk.brandewie@...il.com>
Cc:	Dirk Brandewie <dirk.j.brandewie@...el.com>,
	Linux PM list <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Patrick Marlier <patrick.marlier@...il.com>
Subject: Re: [PATCH 0/2] Add exit_prepare callback to the cpufreq_driver interface.

Hi,

It was a long weekend in India due to some holidays and so couldn't reply.

On Fri, Mar 14, 2014 at 11:59 PM, Dirk Brandewie
<dirk.brandewie@...il.com> wrote:
> On 03/14/2014 10:07 AM, Viresh Kumar wrote:
> Suspend and hotplug are two very different things and if we start
> crossing those wires bad things are going to happen IMHO.
>
> In "normal" operation using the suspend path to do this work could
> work in principal but doesn't handle the case where the user does
>    echo 0 | sudo tee /sys/devices/system/cpu/cpuX/online
>
> Trying force hotplug and suspend into a common mechanism would
> lead to a bunch of special case code or a significant rework of the
> core code IMHO.

What you said is correct, we shouldn't do it. But what I am asking for
is a bit different. The stuff we are doing in core on system suspend
isn't actually related to suspend but only CPU online/offline.

There are platforms which want to set CPUs to a particular frequency
before they are taken out by disable_nonboot_cpus. And then there
are platforms which want to do similar thing when CPUs are taken
down with help of sysfs files. But there is a common baseline there:
Set CPUs to a particular P-state before they are taken down.

And so I wanted to keep a common solution for both these requirements.

> This is guaranteed by the hardware.  Each core has its own MSR for P state
> request.  Any coordination that is required between cores to select the
> package P state is handled by the hardware.

I see.. Let me send some patches which I have in my mind and then we can
decide which set looks more reasonable :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/