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: <20111003163107.GQ3731@opensource.wolfsonmicro.com>
Date:	Mon, 3 Oct 2011 17:31:08 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Rob Herring <robherring2@...il.com>
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, richard.zhao@...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 Mon, Oct 03, 2011 at 10:24:52AM -0500, Rob Herring wrote:
> On 10/03/2011 09:25 AM, Mark Brown wrote:

> > This isn't in any way specific to clocks, right now the likely solution
> > looks to be Grant's changes for retrying probe() as new devices come on
> > line.  With that devices can return a code from their probe() which
> > tells the driver core that they couldn't get all the resources they need
> > and that it should retry the probe() if more devices come on-line.

> Except SOC clocks are initialized very early before timers are up and
> there can be a very high number of dependencies (every clock except
> fixed clocks). With the driver probe retry, retrying is the exception,
> not the rule.

> Retrying would require every caller to maintain a list of clks to
> retry. With 2 stages, you can move that into the core clock code.

They don't need to maintain a list of clocks to retry, they need to
unwind when probe() fails.  But yes.

> There are not typically a large number of board-level/driver created
> clocks, so ensuring correct register order is not really a problem. In
> cases where there is a cross-driver dependency, the probe retry is a
> good solution.

I dunno, I get the impression that some of this is due to the current
limitations of the clock API rather than due to a lack of clocks -
perhaps that's specific to the applications I look at, though.
applications 
--
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/