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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 21 Jan 2011 17:29:33 -0500 (EST)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	Dima Zavin <dmitriyz@...gle.com>,
	Saravana Kannan <skannan@...eaurora.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	linux-sh@...r.kernel.org,
	Ben Herrenschmidt <benh@...nel.crashing.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	lkml <linux-kernel@...r.kernel.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Ben Dooks <ben-linux@...ff.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@...ts.infradead.org
Subject: Re: Locking in the clk API

On Fri, 21 Jan 2011, Russell King - ARM Linux wrote:

> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
> > So I think that the API must be augmented with more methods, such as:
> > 
> > clk_slow_enable():
> >   - may sleep
> >   - may be a no-op if the clk_fast_enable() is supported
> > 
> > clk_fast_enable():
> >   - may not sleep, used in atomic context
> >   - may be a no-op if controlling the clock takes time, in which case 
> >     clk_slow_enable() must have set the clock up entirely
> > 
> > ... and similar for clk_slow_disable() and clk_fast_disable().
> 
> Isn't this along the same lines as my clk_prepare() vs clk_enable()
> suggestion?
> 
> I suggested that clk_prepare() be callable only from non-atomic contexts,
> and do whatever's required to ensure that the clock is available.  That
> may end up enabling the clock as a result.
> 
> clk_enable() callable from atomic contexts, and turns the clock on if
> the hardware supports such an operation.
> 
> So, if you have something like:
> 
> Xtal--->PLL--->Routing/Masking--->Device
> 
> clk = clk_get() returns the clock for the device.
> 
> clk_prepare(clk) would walk up the clock tree, selecting the routing and
> preparing each clock.  Clocks prior to _and_ including the PLL would need
> to be enabled.
> 
> clk_enable(clk) would walk up the tree if the clock isn't already enabled,
> calling clk_enable() on the parent clock.  As we require prepared clocks
> to already be enabled, this automatically stops at the PLL.
> 
> To encourage correct usage, we just need to make sure that clk_prepare()
> has a might_sleep() thing, and clk_enable() throws a fit if it's used
> on a clk without prepare being used first.  The second point is not easy
> to do in a foolproof manner though, but doing _something_ is better than
> nothing.

Exactly.  That model does cover both situations: i.e. clocks with slow 
setups which need to sleep, and clocks with fast setups that can be 
dealt with and taken advantage of within atomic context.  And in some 
cases there is even a mixture of both involved.


Nicolas
--
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/