RFC: Location for Device Tree Sources?

Mark A. Greer mgreer at mvista.com
Thu Aug 3 04:24:15 EST 2006


On Wed, Aug 02, 2006 at 08:35:55AM -0500, Kumar Gala wrote:
> 
> On Aug 1, 2006, at 10:20 PM, Grant Likely wrote:
> 
> > On 8/1/06, Josh Boyer <jwboyer at jdub.homelinux.org> wrote:
> >> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> >>> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> >>>> On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> >>>>>
> >>>>> Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> >>>>> sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >>>>
> >>>> I believe in his latest patches he removed this part. The device  
> >>>> trees
> >>>> were not included at all and he left this point open for  
> >>>> discussion.
> >>>
> >>> That's correct.
> >>>
> >>> TBH, I think its wrong to keep them in the kernel source at all-- 
> >>> yes,
> >>> the same argument could be made for arch/powerpc/boot but that's  
> >>> been
> >>> settled.
> >>
> >> Sorry, I have to disagree.  We're talking about device tree _source_
> >> files here.  I believe they should be included in the kernel source.
> >> Where that is, I don't have a particularly strong argument but they
> >> should be included.
> >
> > I have to second that opinion.  The device tree is absolutely integral
> > with the rest of the code/drivers needed to support a board.  I say
> > there are stronger arguments for keeping the dts files in the kernel
> > source than there are for the boot wrapper.
> >
> > powerpc/boot/dts makes a lot of sense to me.
> 
> I like this location and agree that having them in tree makes sense.   
> And putting them under boot isolates them from the kernel proper.
> 
> The reason I see to having them in tree is to ensure proper version  
> compatibility.  This way there is no concern about which .dts version  
> will work with which kernel.  In the future we can always pull them  
> out when things are more stable.

Hmm, that is a good reason...

Mark



More information about the Linuxppc-dev mailing list