linux-kernel - Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure

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: <20111014100504.GC2966@opensource.wolfsonmicro.com>
Date:	Fri, 14 Oct 2011 11:05:04 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Richard Zhao <richard.zhao@...aro.org>
Cc:	Mike Turquette <mturquette@...com>, linux-kernel@...r.kernel.org,
	paul@...an.com, linaro-dev@...ts.linaro.org,
	linus.walleij@...ricsson.com, patches@...aro.org,
	eric.miao@...aro.org, magnus.damm@...il.com,
	amit.kucheria@...aro.org, grant.likely@...retlab.ca,
	dsaxena@...aro.org, arnd.bergmann@...aro.org,
	shawn.guo@...escale.com, skannan@...cinc.com,
	linux@....linux.org.uk, jeremy.kerr@...onical.com,
	tglx@...utronix.de, linux-arm-kernel@...ts.infradead.org,
	sboyd@...inc.com
Subject: Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure

On Fri, Oct 14, 2011 at 04:10:26PM +0800, Richard Zhao wrote:
> On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:

snip essentially Mike's entire mail - *please* delete irrelevant quotes
from your replies, it makes it very much easier to find the new text in
your mail and is much more friendly to people reading mail on mobile
devices.

> > +static int __clk_enable(struct clk *clk)
> > +{

> Could you expose __clk_enable/__clk_disable? I find it hard to implement
> clk group. clk group means, when a major clk enable/disable, it want a set
> of other clks enable/disable accordingly.

Shouldn't this be something the core is implementing?  I'd strongly
expect that the clock drivers are relatively dumb and delegate all the
decision making to the core API.  Otherwise it's going to be hard for
the core to implement any logic that involves working with more than one
clock like rate change notification, or guarantee that driver requests
made through the API are satisfied, as the state of the clocks will be
changing underneath it.
--
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/