[GIT PULL] at91: DT changes for 3.10 #2

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:19 Thu 04 Apr     , Olof Johansson wrote:
> On Thu, Apr 4, 2013 at 2:37 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> > On 04/03/2013 09:45 AM, Nicolas Ferre :
> >> On 04/02/2013 08:49 PM, Olof Johansson :
> >>> On Fri, Mar 29, 2013 at 03:59:39PM +0100, Nicolas Ferre wrote:
> >>>> Arnd, Olof,
> >>>>
> >>>> Here is a pull-request for AT91 that is dedicated to Device Tree
> >>>> modifications. It is stacked on the material that you already have
> >>>> for 3.10 in your arm-soc/at91/dt branch.
> >>>> Following our discussion with Arnd, I added the non-urgent patches that I
> >>>> already proposed too late for 3.9. I also included the moving of macb node
> >>>> and kept the original patch.
> >>>>
> >>>> Thanks, best regards,
> >>>>
> >>>> The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362:
> >>>>
> >>>>   ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100)
> >>>>
> >>>> are available in the git repository at:
> >>>>
> >>>>   git://github.com/at91linux/linux-at91.git tags/at91-dt
> >>>>
> >>>> for you to fetch changes up to cc2e191b0ccc5a987fdb29261ab9c264c608924d:
> >>>>
> >>>>   ARM: at91/dt: fix macb node declaration (2013-03-29 10:02:04 +0100)
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> One macb DT node move for 9x5 family: 9g15 doesn't
> >>>> have an Ethernet interface.
> >>>> Little fixes mainly related to at91sam9x5 DT and the
> >>>> RTC addition.
> >>>> Addition of the Acme Systems Aria G25 board.
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> Douglas Gilbert (1):
> >>>>       ARM: at91: add Acme Systems Aria G25 board
> >>>
> >>> Hi,
> >>>
> >>> I just replied to the above patch -- please prefix the dts files with the
> >>> platform so it's easier to navigate the directory.
> >
> > I do not want to spark a debate here, but moving to directories per
> > "mach" earlier would have made things easier. If I recall well,
> > Jean-Christophe has proposed it a long time ago...
> 
> Yeah, we're at a size where it's starting to be warranted (powerpc
> does so already). It does cut down on the cross-exposure and review
> though and puts everyone in their own little sandbox, so there's some
> benefit in keeping it flat.
> 
> I think that benefit is losing its appeal though. But let's hold off
> for another couple of releases with the churn of moving things out in
> subdirectories.
> 
> >> Yes, I have to make sure that everybody agree on our side...
> >
> > The difficult point with this prefix... well it is difficult to tell...
> > our product will never be called "at91" again!
> 
> That's a marketing issue, not a technical kernel one. If we create
> subdirectory it makes sense to name it 'atmel' instead of 'at91'
> though, I'm sure.
> 
> > So, yes, our Linux identity is still "at91" and we are pretty attached
> > to it but our newer products are named "sam" + "core" + "product family"
> > which results in our newer family: "sama5d3" (note the at91 is missing)...
> > => anyway, we think that the at91 prefix is still vivid in Linux
> > community and we consider it as a good choice for now.
> > So, I may rename the newly introduced "sama5d3*.dts[i]" files with
> > "at91-sama5d3*.dts[i]" (while .c/.h files will remain the same).
> 
> Sounds reasonable, or stick to the same format as you already have
> with at91sam9 families. When we move to subdirectories it might make
> sense to stick them under 'atmel' instead of 'at91' though and drop
> the prefix.
I've a rfc for this as I do no lihe idea of prefix

and it make the grep search mo complex

I send a patch to clean the '\\' stuff in this Makefile

can you take

I send the dir split on the top of this
> 
> 
> 
> -Olof