mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jason Cooper <jason@lakedaemon.net>
To: Kumar Gala <galak@codeaurora.org>
Cc: devicetree@vger.kernel.org,
	"linux-kernel@vger.kernel.org list"
	<linux-kernel@vger.kernel.org>
Subject: Re: common location for devicetree files
Date: Fri, 8 Nov 2013 13:13:51 -0500	[thread overview]
Message-ID: <20131108181351.GF10335@titan.lakedaemon.net> (raw)
In-Reply-To: <5957C301-9698-45B0-BFED-749DE79D0A74@codeaurora.org>

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.

  reply	other threads:[~2013-11-08 18:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-07 23:21 Kumar Gala
2013-11-08 16:52 ` Jason Cooper
2013-11-08 17:59   ` Kumar Gala
2013-11-08 18:13     ` Jason Cooper [this message]
2013-11-08 18:17       ` Kumar Gala
2013-11-08 18:32         ` Jason Cooper
2013-11-11 16:24           ` Stephen Warren
2013-11-11 16:34             ` Jason Cooper
2013-11-11 17:35             ` Mark Rutland
2013-11-08 19:33 ` Olof Johansson
2013-11-08 19:37   ` Jason Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131108181351.GF10335@titan.lakedaemon.net \
    --to=jason@lakedaemon.net \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®