linux-kernel - Re: [PATCH 21/21] clk: ux500: Supply provider look-up functionality to support Device Tree

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] [day] [month] [year] [list]

Message-Id: <20130612125607.5C13E3E0A56@localhost>
Date:	Wed, 12 Jun 2013 13:56:07 +0100
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Linus Walleij <linus.walleij@...aro.org>,
	Lee Jones <lee.jones@...aro.org>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>,
	Linus WALLEIJ <linus.walleij@...ricsson.com>,
	Srinidhi KASAGAR <srinidhi.kasagar@...ricsson.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Mike Turquette <mturquette@...aro.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>
Subject: Re: [PATCH 21/21] clk: ux500: Supply provider look-up functionality to support Device Tree

On Tue, 4 Jun 2013 12:57:06 +0200, Linus Walleij <linus.walleij@...aro.org> wrote:
> On Mon, Jun 3, 2013 at 3:42 PM, Lee Jones <lee.jones@...aro.org> wrote:
> 
> > In this patch we're populating a clk_data array, one clock per element to
> > act as a clk look-up using indexes supplied from Device Tree.
> >
> > Cc: Mike Turquette <mturquette@...aro.org>
> > Signed-off-by: Lee Jones <lee.jones@...aro.org>
> 
> This needs to be patch 1/21 because otherwise the rest of the
> stuff is non-bisectable right? It's being broken the first time
> you remove auxdata and not fixed until this patch.
> 
> The whole thing is very different from other DT clock things
> I've seen, usually you add a compatible node for each
> clock type, and a node for each physical gate. But there
> may be several ways to skin this cat...

The design choice made here is perfectly fine by me. There has never
been a requirement to expose every clock as a separate node, and for
SoCs with complex clock control blocks I can certainly appreciate not
wanting to expose how the internal clocks interact out to the device
tree, especially if only the leaf clocks ever get reverenced by device
drivers. As long as there is a driver there that understands the binding
and hands out the correct clock when asked, then this design is great.

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