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: <20111003142524.GN3731@opensource.wolfsonmicro.com>
Date:	Mon, 3 Oct 2011 15:25:24 +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 09:17:30AM -0500, Rob Herring wrote:
> On 09/22/2011 05:26 PM, Mike Turquette wrote:

A lot of stuff that should really have been cut plus...

> > +	if (clk->ops->get_parent)
> > +		/* We don't to lock against prepare/enable here, as
> > +		 * the clock is not yet accessible from anywhere */
> > +		clk->parent = clk->ops->get_parent(clk->hw);

> I don't think this is going to work. This implies that the parent clock
> is already registered. For simple clk trees, that's probably not an
> issue, but for chips with lots of muxing it will be impossible to get
> the order correct for all cases. This is not an issue today as most
> clocks are statically created.

> I think what is needed is a 2 stage init. The 1st stage to create all
> the clocks and a 2nd stage to build the tree once all clocks are created.

> Tracking the parents using struct clk_hw instead would help as long as
> clocks are still statically allocated. However, that won't help for
> devicetree.

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