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: <4D31DCF6.7090805@weinigel.se>
Date:	Sat, 15 Jan 2011 18:44:22 +0100
From:	Christer Weinigel <christer@...nigel.se>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
CC:	Saravana Kannan <skannan@...eaurora.org>,
	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 01/15/2011 06:20 PM, Russell King - ARM Linux wrote:
 > You really need to read the entire thread - I've already said that yet

> discussion continues about how to solve the problem.  This thread which
> has been running for a number of days now has been entirely about how
> to solve this.


Sigh, the always oh so polite Russell.  I have read the thread before; I 
reread the whole thread one more time before posting.

> Consider this: is it better to continue talking about this for the next
> six months, while still having N spinlock based implementations, and M
> mutex based implementations.
>
> Or is it better to consolidate the N spinlock based implementations
> down to one spinlock implementation, and M mutex based implementations
> down to one mutex implementation, and then discuss how to resolve the
> differences between the two implementations?


Going that way might very well mean that you will be stuck with two 
implementations forever.  But yes, it might be better with two working 
ones than one which takes a bit longer to finish.

But my impression is that the different suggestions in the thread aren't 
that far apart.  Except for the discussion if clk_enable/disable should 
be able to sleep or not, people seem to agree on most of the rest of the 
API.

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