From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] imx cleanup for 3.9
Date: Tue, 29 Jan 2013 08:26:03 +0100 [thread overview]
Message-ID: <20130129072603.GL1906@pengutronix.de> (raw)
In-Reply-To: <20130129010853.GA24352@S2101-09.ap.freescale.net>
On Tue, Jan 29, 2013 at 09:08:55AM +0800, Shawn Guo wrote:
> On Mon, Jan 28, 2013 at 02:00:26PM -0800, Olof Johansson wrote:
> > Hi,
> >
> > On Tue, Jan 22, 2013 at 10:48:15PM +0800, Shawn Guo wrote:
> >
> > > Shawn Guo (4):
> > > ARM: dts: imx: use nodes label in board dts
> >
> > Hmm.
> >
> > This patch is 1000 lines of pure churn. Sure, the style on OMAP is different,
> > but there's no clear benefit from it -- it's actually advantageous to see some
> > of the bus hierarchies even on the leaf-level board nodes.
> >
> > Would you mind respinning with this left out, please? If you still want to
> > argue it to be included, we can do so, but I'd like to pick up the rest of the
> > branch meanwhile. :-)
>
> I will refresh the pull-request to leave it out, but meanwhile I'd like
> to argue too, as the approach has been agreed by IMX people and all the
> patches I queued on imx/dt are all in this way. And I will move the
> patch to imx/dt branch instead, if you're not strongly against the
> approach.
>
> The board level dts are mostly used to add/overwrite properties for
> nodes defined in soc dts. Therefore, what people who look at board
> dts care about is those properties, not really which bus the nodes
> are on. We go this way to have board dts focus on the things they
> are created for. It's much easer to read and edit those properties.
>
> I'm not sure why it's important to maintain the bus topology in board
> dts while we have the full one in soc dts. In the current way, people
> sometimes have to reassemble 3 or more levels bus hierarchies for only
> overwriting one property for one node.
>
> I'm pretty sure that people who work on board level dts would vote for
> this way. It makes their life easier without increasing the
> maintainer's burden. So why not?
I'm with Shawn here. With this board layout I'm now able to write board
dts files without looking much at the dtsi file at all. It's debatable
if existing boards have to be changed to use this layout, but since
people copy-paste all the time changing it increases the chance they
copy the right stuff.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2013-01-29 7:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-22 14:48 [GIT PULL] imx cleanup for 3.9 Shawn Guo
2013-01-28 22:00 ` Olof Johansson
2013-01-29 1:08 ` Shawn Guo
2013-01-29 7:26 ` Sascha Hauer [this message]
2013-01-29 14:18 ` Olof Johansson
2013-01-29 15:10 ` Shawn Guo
2013-01-29 15:15 ` Fabio Estevam
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=20130129072603.GL1906@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).