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: <20110120190822.GK6335@n2100.arm.linux.org.uk>
Date:	Thu, 20 Jan 2011 19:08:22 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Ben Dooks <ben-linux@...ff.org>
Cc:	Richard Zhao <linuxzsc@...il.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	linux-sh <linux-sh@...r.kernel.org>,
	Ben Herrenschmidt <benh@...nel.crashing.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Locking in the clk API

On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
> If you want to make it so that each low-power mode has to work
> out what PLLs need to be disabled and then re-enabled makes me
> want to be sick. Hiding this stuff behind specific implementations
> is a recipe for disaster.

Why should systems which don't suffer from such problems be prevented
from gaining power saving from turning off their clocks when devices
are not being used (eg, the console serial port.)

One solution to your root PLL issue would be to have a separate set of
enable/disable API calls which get called at setup/release time (or
whatever you'd like to call it) which can only be called from non-atomic
context.  Maybe clk_prepare() and clk_unprepare().  These functions
should perform whatever is necessary to ensure that the clock source
is available for use atomically when clk_enable() is called.

So, in your case, clk_prepare() ensures that the root PLL is enabled,
clk_unprepare() allows it to be turned off.

In the case of a console driver, clk_prepare() can be called when we
know the port will be used as a console.  clk_enable() is then called
before writing out the string, and clk_disable() after we've completely
sent the last character.

This allows the best of both worlds.  We now have a clk_enable() which
can be used to turn the clocks off through the clock tree up to the first
non-atomic clock, and we also have a way to deal with those which need
to sleep.  So not only do "sleeping clock" implementations become possible
but these "sleeping clock" implementations also get the opportunity to
shutdown some of their clock tree with minimal latency for doing so.
--
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/