From: Robert Schwebel <r.schwebel@pengutronix.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: How to add platform specific data to a of_device
Date: Mon, 16 Jul 2007 09:19:36 +0200 [thread overview]
Message-ID: <20070716071936.GK1678@pengutronix.de> (raw)
In-Reply-To: <1184569752.25235.46.camel@localhost.localdomain>
On Mon, Jul 16, 2007 at 05:09:12PM +1000, Benjamin Herrenschmidt wrote:
> As I wrote a couple of times already, it's a perfectly acceptable
> approach to have "constructors" (what you call oftree-interpreter) that
> generate platform devices from the OF tree.
Great!
> > mapping. Is there a reason why there is sooo much interaction of the
> > platform code with the oftree? We usually have the situation that, if
> > something goes wrong, you have to change
> >
> > - the driver
> > - the platform code
> > - the oftree
>
> There should generally be no need to change the platform code.
Well, in reality it is, because for example the MPC52xx PSC SPI
controller we are currently working was obviously never tested with
oftree before it hit the mainline ...
> > and they often contain redundant information (like names of oftree
> > nodes, which change more often than some people's panties).
>
> Well, they aren't supposed to :-) The problem at this point is more due
> to the fact that for things that haven't been specified by official OF
> bindings, people are going all over trying to define their own and
> sometimes conflicting bindings and then changing them.
I think it is a fundamental thing: the "we just have to wait long
enough, until oftree definitions have settled" proposal just isn't
right. It may be right for big irons, being well defined. But for the
embedded processors, too less people are working on it, plus we have too
much things which could be defined. Speaking of the MPC5200, look at how
often device tree names change, e.g. for mpc5200 vs. mpc52xx vs.
whatever. As long as things change, you have to keep the three locations
in sync manually, and that's bad.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
next prev parent reply other threads:[~2007-07-16 7:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-14 16:31 How to add platform specific data to a of_device Juergen Beisert
2007-07-14 20:48 ` Benjamin Herrenschmidt
2007-07-15 8:33 ` Juergen Beisert
2007-07-15 8:57 ` Benjamin Herrenschmidt
2007-07-16 16:13 ` Segher Boessenkool
2007-07-16 6:51 ` Robert Schwebel
2007-07-16 7:09 ` Benjamin Herrenschmidt
2007-07-16 7:19 ` Robert Schwebel [this message]
2007-07-16 7:29 ` Benjamin Herrenschmidt
2007-07-16 16:47 ` Segher Boessenkool
2007-07-16 16:28 ` Segher Boessenkool
2007-07-16 7:40 ` Michael Ellerman
2007-07-16 16:16 ` Segher Boessenkool
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=20070716071936.GK1678@pengutronix.de \
--to=r.schwebel@pengutronix.de \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.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).