linux-kernel - Re: Locking in the clk API

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <AANLkTikUT6ds6+omkmr2rgUipq=nmEd6GRPngK0+qUZ4@mail.gmail.com>
Date:	Tue, 11 Jan 2011 17:41:24 +0530
From:	Jassi Brar <jassisinghbrar@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-sh@...r.kernel.org,
	Ben Herrenschmidt <benh@...nel.crashing.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	linux-kernel@...r.kernel.org,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: Locking in the clk API

On Tue, Jan 11, 2011 at 2:46 PM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>> At present, we can satisfy these with:
>>
>> * clk_enable: may sleep
>
> I object to this as one of the purposes behind the clk API is to allow
> power savings to be made, and unless we can perform clk enable/disable
> from atomic contexts, the best you can do is enable the clock when the
> device is probed and disable it when it's released.
>
> For a lot of systems, modules are loaded at boot, and devices are probed
> at boot time.  They're never unloaded.
>
> This means that clocks will be enabled at boot time and never turned off.
>
> If you're lucky, there may be open/release methods which can be used to
> enable/disable the clock, which reduces the 'clock on' period down to
> the point where userspace opens/closes the device.  That's still
> insufficient and in some cases there aren't calls for this.
>
> Sometimes the only point that you know you need the clock enabled is when
> your driver has already been called in an atomic context.
>
> If such a requirement is imposed, it means that a driver would either have
> to leave the clock always on, or would have to drop such calls if the
> clock wasn't already enabled.

Perhaps we should factor the conventional clk_enable into two parts (say) :-
 a)  clk_setup  : Which does exactly what can't be done in atomic context.
                         Like setting PLLs i.e, if that needs to sleep.
b)  clk_enable : Everything else that gets the clock signals running.

The drivers could do clk_setup in probe/open and clk_enable right before the
the actual need of the clock. That way, drivers don't have to bother
with platform/clock
peculiarities while trying their best to save power.
Of course, power that can't be saved now, won't be saved then.
--
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/