Re: common location for devicetree files

[Jason Cooper]

On Fri, Nov 08, 2013 at 11:59:56AM -0600, Kumar Gala wrote:
> 
> On Nov 8, 2013, at 10:52 AM, Jason Cooper wrote:
> 
> > On Thu, Nov 07, 2013 at 05:21:58PM -0600, Kumar Gala wrote:
> >> As we start having more sharing of device trees between architectures
> >> (arm & arm64, arm & powerpc, guessing maybe mips & arm) we need dts to
> >> live in location that 
> >> 
> >> I was wondering what people felt about doing:
> >> 
> >> 	arch/dts/<VENDOR>/
> >> 
> >> as a common location that could be shared.  I'm up for other
> >> suggestions.
> > 
> > What do we really need to do before the move?  Should all arch dts files
> > be able to #include from any arch?  What's the minimum churn needed to
> > accomplish that?  Maybe just move the needed bits to arch/dts/include/ ?
> > 
> > I'm not real keen on separating by vendor.  For example, us mvebu folks
> > would probably miss useful/duplicated effort in another vendor's
> > subdirectory.  Which was the whole reason for moving driver code out of
> > machine directories to begin with.
> 
> 
> Can you explain that further, what would you miss from other vendors.
> All the patches should still be going via devicetree ML.

I was simply applying the same logic used to justify moving all of the
driver code out of arch/arm/.  Once that happened, a lot of patterns
emerged and we have things like common clock now.  Yet all of this code
(originally under arch/arm) was submitted to the same ML.

iow, there's a difference between being on the same high-traffic
mailinglist where people are filtering out just what they need, and
being in the same subdirectory, right next to three other
implementations of the same code (I exaggerate, but the point remains).
It's a lot easier to spot similar implementations when they are all
congregated under one directory.

How many boards are using the same PMIC across vendors?  Would it make
sense to have a tps6905.dtsi they could all include?  Flash chips?  I'm
just asking.

My gut is that having separate vendor directories would lead to
balkanization.  That might not be a problem, but it's worth considering.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/