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: <20110111101314.GA774@linux-sh.org>
Date:	Tue, 11 Jan 2011 19:13:14 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Jeremy Kerr <jeremy.kerr@...onical.com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-sh@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Ben Herrenschmidt <benh@...nel.crashing.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Uwe Kleine-K?nig <u.kleine-koenig@...gutronix.de>
Subject: Re: Locking in the clk API

On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
> So, it sounds like the best approach is to provide an atomic clk_enable. I 
> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
> most sense, so how about:
> 
> int clk_enable(struct clk *clk)
> {
> 	might_sleep();
> 
> 	[...]
> }
> 
> int clk_enable_atomic(struct clk *clk)
> {
> 	BUG_ON(!(clk->flags & CLK_ATOMIC));
> 
> 	[...]
> }
> 
> Paul: even though you mention that the atomic clocks are the usual case, I 
> think that this way around illustrates the atomic 'restriction' at the call 
> site more clearly. When the drivers don't care about the atomicity, 
> clk_enable() is fine. When drivers do need an atomic clock, 
> clk_enable_atomic() shows this requirement.
> 
No, the sleeping clock case is and always will be a corner case, and I
have no interest in pretending otherwise. On SH we have hundreds of
clocks that are all usable in the atomic context and perhaps less than a
dozen that aren't (and even in those cases much of the PLL negotiation is
handled in hardware so there's never any visibility for the lock-down
from the software side, other architectures also have similar behaviour).

Keep in mind that all users except for the few that you cited were
already quite content with the atomic context use, so this 'restriction'
you speak of is just an artificial limitation introduced by a couple of
new platforms that deviated from what everyone else was already doing.

If you want to go this route, then SH and ARM-based SH-Mobiles will at
least not be making use of the generic struct clk.
--
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/