linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-dev@ozlabs.org, Sean MacLennan <smaclennan@pikatech.com>
Subject: Re: How complete should the DTS be?
Date: Thu, 10 Jan 2008 17:50:49 +1100	[thread overview]
Message-ID: <1199947849.6734.231.camel@pasglop> (raw)
In-Reply-To: <20080110060245.GE19088@localhost.localdomain>


On Thu, 2008-01-10 at 17:02 +1100, David Gibson wrote:
> On Thu, Jan 10, 2008 at 12:53:57AM -0500, Sean MacLennan wrote:
> > David Gibson wrote:
> > > Hrm... I'd say this is not something which has a firm convention yet.
> > > It's going to become more of an issue once we get a macros system for
> > > dtc, so the "440EP" macro would have all the devices, even if some are
> > > not connected on a given board.
> > >
> > > I'm contemplating suggesting that we adopt the "status" property from
> > > IEEE1275 to cover this.
> > >
> > >   
> > When I am laying out the dts, leaving out what isn't used makes the dts 
> > file cleaner, at least in my view. It doesn't hurt to have the second 
> > i2c bus there, but it also doesn't help and leaving it out points out 
> > that it is not used.
> > 
> > When we get a macro system I assume the second i2c bus will be there but 
> > hidden by a macro. It will still be clean and shouldn't cause grief.
> 
> Right, but if it is there we'll want to mark it as unused in some way
> so that the kernel doesn't waste resources attempting to drive it.

Sure but I don't want to make it mandatory for people to put unused
devices in. If the macro system brings them in, then yes, it's good to
have a way to properly mark them unused. But people hand crafting DTS
shouldn't have to bloat them.

There is -one- case where you may want to put unused devices, is if you
do some kind of resource management on that specific bus (like need to
be able to dynamically allocate space on the bus). In this case, you
want to know everything that's there and potentially decodes addresses
to avoid collisions.

Cheers,
Ben.

  reply	other threads:[~2008-01-10  6:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-08  2:07 How complete should the DTS be? Sean MacLennan
2008-01-08  6:04 ` Kumar Gala
2008-01-10  3:13   ` David Gibson
2008-01-10  5:53     ` Sean MacLennan
2008-01-10  6:02       ` David Gibson
2008-01-10  6:50         ` Benjamin Herrenschmidt [this message]
2008-01-10 13:58           ` Josh Boyer

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=1199947849.6734.231.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=smaclennan@pikatech.com \
    /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;
as well as URLs for NNTP newsgroup(s).