From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Robert Schwebel <r.schwebel@pengutronix.de>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
devicetree-discuss <devicetree-discuss@ozlabs.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.arm.linux.org.uk,
Jon Smirl <jonsmirl@gmail.com>,
Scott Wood <scottwood@freescale.com>,
Janboe Ye <yuan-bo.ye@motorola.com>,
Timur Tabi <timur@freescale.com>
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform
Date: Thu, 28 May 2009 17:55:43 +1000 [thread overview]
Message-ID: <1243497343.3171.158.camel@pasglop> (raw)
In-Reply-To: <20090528063445.GA12004@pengutronix.de>
On Thu, 2009-05-28 at 08:34 +0200, Wolfram Sang wrote:
>
> > OTOH, if it is appropriate for the device, then the binding can be defined to
> > include things like page size and flags encoded explicitly in additional
> > properties.
>
> ..., so I think a property like "page-size" could really be argumented for.
Most definitely. And it's in fact reasonably easy to define such
bindings. And if somebody later decide do invent a fancier property
called "page-data" that contains more structured informations, the
driver can still fall back to using "page-size" when the later is not
found. It's rarely needed but the technique works reasonably well.
> Actually, I am quite optimistic that there could be agreement on it. Maybe we
> could also reuse the "read-only" property which is used for partitions. Still,
> this discussion has to be done, and that is additional work for mainlining.
Well, it depends. You don't need to have defined all the bindings for
all possible devices on the planet before adding to your architecture
the core bits to have the ability to use device-trees :-)
However, it does make sense for a platform using it, to at least try
to make sure that bindings for the devices it uses are in reasonable
shape.
Again, no solution is ever perfect and whatever the technique is,
somebody can make a mess of it. But my experience is that most of
the time, those things come pretty easily out of common sense when
talking about bindings for a -device-. Bindings for -busses- take
a bit more thoughts, I agree.
> Also, this would be _another_ wrapper to collect data from the device tree and
> pass it into platform_data.
> I think it is difficult to maintain.
It's easier to have -one- piece of code taking data for device type X
to create the platform data and than all platforms around having C code
spread around that manufactures that platform data in 36 different ways.
So here, I disagree.
> If somebody
> extends at24 and forgets about the of-wrapper, it may easily get broken.
No. If somebody adds new fields and not knowing about them doesn't break
existing users, then only the first person to try to use the new
functionality will discover the need for a new property and update the
wrapper.
If somebody however changes the platform data in incompatible ways, that
person is supposed to fix all users right ? So grep all platforms etc...
and the wrapper will show up in that grep.
Also, it might be a lot easier to change just the wrapper don't you
think ? :-)
> Plus,at least for me, coding always very similar stuff, feels like bloating the
> kernel. I did it a few times now, and that made me really wonder if we can't
> have a more generic solution to that problem. Sadly, I could neither come up
> with anything useful :(
Well, the device-tree does avoid a -lot- of code duplication... you can
see that easily when you look at our 4xx based platforms today vs. what
they were in arch/ppc
Cheers,
Ben.
next prev parent reply other threads:[~2009-05-28 7:59 UTC|newest]
Thread overview: 151+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-27 7:08 [RFC] [PATCH] Device Tree on ARM platform Janboe Ye
2009-05-27 14:27 ` Grant Likely
2009-05-27 14:39 ` Timur Tabi
2009-05-27 15:05 ` Robert Schwebel
2009-05-27 15:39 ` Grant Likely
2009-05-27 16:20 ` Robert Schwebel
2009-05-27 20:35 ` Grant Likely
2009-05-27 23:48 ` Robert Schwebel
2009-05-27 23:52 ` David Miller
2009-05-27 23:58 ` Scott Wood
2009-05-28 0:02 ` David Miller
2009-05-28 0:07 ` Robert Schwebel
2009-05-28 0:15 ` David Miller
2009-05-28 10:37 ` Mark Brown
2009-05-28 22:32 ` Grant Likely
2009-05-29 12:34 ` Mark Brown
2009-05-30 9:52 ` Benjamin Herrenschmidt
2009-05-30 10:21 ` Russell King - ARM Linux
2009-05-30 17:56 ` Mark Brown
2009-06-02 7:57 ` Holger Schurig
2009-06-02 9:48 ` Mark Brown
2009-05-28 2:57 ` David Gibson
2009-05-28 3:36 ` Grant Likely
2009-05-28 3:29 ` Grant Likely
2009-05-28 9:51 ` Wolfgang Denk
2009-05-28 9:59 ` David Miller
2009-05-28 10:13 ` Robert Schwebel
2009-05-28 13:33 ` Jon Smirl
2009-05-28 13:42 ` Robert Schwebel
2009-05-28 9:38 ` Wolfgang Denk
2009-05-28 3:21 ` Grant Likely
2009-05-28 3:16 ` Grant Likely
2009-05-28 0:55 ` Stephen Neuendorffer
2009-05-27 18:56 ` Alexander Clouter
2009-05-27 20:46 ` Grant Likely
2009-05-27 21:32 ` Alexander Clouter
2009-05-27 15:41 ` Peter Korsgaard
2009-05-27 16:23 ` Scott Wood
2009-05-27 17:56 ` Russell King
2009-05-27 19:08 ` Scott Wood
2009-05-27 19:13 ` Jon Smirl
2009-05-27 19:21 ` Russell King - ARM Linux
2009-05-27 19:39 ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-27 20:22 ` Grant Likely
2009-05-27 20:19 ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-27 20:54 ` Grant Likely
2009-05-28 3:04 ` David Gibson
2009-05-28 7:58 ` Benjamin Herrenschmidt
2009-05-27 23:57 ` Robert Schwebel
2009-05-28 0:00 ` David Miller
2009-05-28 3:21 ` Grant Likely
2009-05-28 6:34 ` Wolfram Sang
2009-05-28 7:55 ` Benjamin Herrenschmidt [this message]
2009-05-28 13:34 ` Grant Likely
2009-05-28 7:48 ` Benjamin Herrenschmidt
2009-05-28 14:22 ` Ben Dooks
2009-05-27 20:28 ` David Miller
2009-05-27 20:31 ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-28 2:52 ` David Gibson
2009-05-28 4:27 ` David Miller
2009-05-28 4:47 ` David Gibson
2009-05-28 5:31 ` David Miller
2009-05-28 5:47 ` David Gibson
2009-05-28 7:47 ` Benjamin Herrenschmidt
2009-05-28 14:17 ` Ben Dooks
2009-05-28 14:24 ` Robert Schwebel
2009-05-28 14:47 ` Grant Likely
2009-05-27 19:29 ` Russell King
2009-05-27 19:47 ` Sergei Shtylyov
2009-05-27 19:53 ` Scott Wood
2009-05-27 19:54 ` Timur Tabi
2009-05-27 20:25 ` David Miller
2009-05-27 20:27 ` Timur Tabi
2009-05-27 20:55 ` David Miller
2009-05-27 23:26 ` Robert Schwebel
2009-05-27 20:35 ` M. Warner Losh
2009-05-27 20:14 ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-27 20:23 ` David Miller
2009-05-27 20:27 ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-27 20:48 ` Josh Boyer
2009-05-27 20:56 ` David Miller
2009-05-27 20:52 ` Mark Brown
2009-05-27 21:05 ` Grant Likely
2009-05-28 0:11 ` Jon Smirl
2009-05-28 12:43 ` Sascha Hauer
2009-05-28 13:18 ` Thomas Gleixner
2009-05-28 15:04 ` Sascha Hauer
2009-05-28 15:27 ` Thomas Gleixner
2009-05-29 0:51 ` Benjamin Herrenschmidt
2009-05-29 7:52 ` Sascha Hauer
2009-05-29 9:08 ` Benjamin Herrenschmidt
2009-05-31 10:52 ` Russell King - ARM Linux
2009-05-28 14:31 ` Grant Likely
2009-05-28 3:25 ` David Gibson
2009-05-28 8:10 ` Benjamin Herrenschmidt
2009-05-28 7:38 ` Benjamin Herrenschmidt
2009-05-27 20:43 ` Grant Likely
2009-05-28 7:37 ` Benjamin Herrenschmidt
2009-05-28 9:15 ` Russell King - ARM Linux
2009-05-28 9:57 ` David Miller
2009-05-28 10:11 ` Benjamin Herrenschmidt
2009-05-28 10:33 ` Robert Schwebel
2009-05-28 10:34 ` Russell King - ARM Linux
2009-05-28 22:33 ` Benjamin Herrenschmidt
2009-05-28 10:14 ` Russell King - ARM Linux
2009-05-28 21:30 ` David Miller
2009-05-28 12:17 ` Dmitry Eremin-Solenikov
2009-05-28 12:48 ` David Gibson
2009-05-28 12:55 ` David Gibson
2009-05-28 14:13 ` Grant Likely
2009-05-28 16:53 ` Russell King - ARM Linux
2009-05-28 17:05 ` Grant Likely
2009-05-28 18:46 ` Alexander Clouter
2009-05-28 22:21 ` Benjamin Herrenschmidt
2009-05-29 1:39 ` David Gibson
2009-05-29 1:59 ` Mitch Bradley
2009-05-29 3:52 ` Benjamin Herrenschmidt
2009-05-29 4:11 ` David Miller
2009-05-29 4:11 ` David Miller
2009-05-29 4:56 ` Benjamin Herrenschmidt
2009-05-29 5:11 ` David Miller
2009-05-28 10:00 ` Benjamin Herrenschmidt
2009-05-28 11:44 ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-28 12:47 ` Jon Smirl
2009-05-28 14:39 ` Grant Likely
2009-05-28 14:54 ` Grant Likely
2009-05-27 18:26 ` Peter Korsgaard
2009-05-27 16:32 ` Mark Brown
2009-05-27 18:50 ` Jon Smirl
2009-05-27 22:24 ` Mark Brown
2009-05-28 0:04 ` Jon Smirl
2009-05-28 13:07 ` Mark Brown
2009-05-27 20:42 ` Grant Likely
2009-05-27 21:38 ` Mark Brown
2009-05-28 3:02 ` David Gibson
2009-05-28 7:32 ` Benjamin Herrenschmidt
2009-05-28 13:38 ` Grant Likely
2009-05-27 22:01 ` Mitch Bradley
2009-05-28 8:17 ` Benjamin Herrenschmidt
2009-05-28 12:43 ` Holger Schurig
2009-05-28 13:12 ` Mark Brown
2009-05-27 17:44 ` Russell King
2009-05-27 17:52 ` Grant Likely
2009-05-28 3:44 ` David Gibson
2009-05-30 11:22 ` Pavel Machek
2009-05-31 1:29 ` Kyle Moffett
2009-05-31 5:56 ` David Miller
2009-06-01 8:37 ` Dmitry Eremin-Solenikov
2009-05-31 10:08 ` Russell King - ARM Linux
2009-06-01 9:24 ` Stephen Rothwell
2009-06-01 10:36 ` Janboe Ye
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=1243497343.3171.158.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=devicetree-discuss@ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=jonsmirl@gmail.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=plagnioj@jcrosoft.com \
--cc=r.schwebel@pengutronix.de \
--cc=scottwood@freescale.com \
--cc=timur@freescale.com \
--cc=w.sang@pengutronix.de \
--cc=yuan-bo.ye@motorola.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