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

On Tue, Jan 11, 2011 at 09:18:16PM +0900, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:
> > Hi Paul,
> > 
> > > 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).
> > 
> > I'm not too worried about the corner-cases on the *implementation* side, more 
> > the corner-cases on the API side: are we seeing more users of the API that 
> > require an atomic clock, or more that don't care?
> > 
> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour. Sleeping for
particularly if atomic behaviour is the common behaviour it's important
to get it right, because the less common sleeping clocks don't get much
test covering.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ