[GIT PULL] at91: cleanup for 3.16 #1

Olof Johansson olof at lixom.net
Mon May 19 21:25:25 PDT 2014


[adding Mark]

On Sat, May 17, 2014 at 06:22:16AM +0200, Alexandre Belloni wrote:
> On 16/05/2014 at 16:26:35 -0700, Olof Johansson wrote :
> > On Wed, May 07, 2014 at 07:39:35PM +0200, Nicolas Ferre wrote:
> > > There is a little conflict with at91-3.16-dt that you already pulled in
> > > arm-soc: here is the branch that resolves it:
> > > 
> > > https://github.com/at91linux/linux-at91/commits/at91-3.16-resolved
> > 
> > That resolution looks odd. Why is one clock under clocks { } and two of them
> > are at the top level? Shouldn't they all be under the clocks subnode?
> > 
> > I've merged in now with your resolution, but I think this needs revisiting.
> > 
> 
> Actually, all the clocks should end up at the root, please refer to:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/240219.html
> 
> I feel that was one of the topics we should have discussed at ELC but we
> ended up talking about DT ABI stability instead...

I'm looking more for consistency than anything else. Having a few in the
root and the few in a subnode certainly indicates that something's wrong.

It's a good thing that we have several DT maintainers to spread the load,
but it's also harder to learn the preferences of the maintainer(s) since
there seems to be variety (some care more about some things than others).

I'm not saying that Mark is wrong, but it's quite possible that someone
else would disagree or not care enough to point it out. The current
practice of having clocks under a subnode is prevalent almost everywhere
in the tree, and this is a mostly new direction set by Mark. It makes
it very hard to figure out what's the best way to do things when there's
less consistency.

Clearly, having clocks grouped in a subnode is common practice already, and
makes some sense from a readability point of view.

Anyway, I'll leave the rest for some DT maintainer to sort out. Please
follow up with patches to switch over to one or the other model no matter
what, please.


-Olof



More information about the linux-arm-kernel mailing list