From: Lee Jones <lee.jones@linaro.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Wolfram Sang <w.sang@pengutronix.de>,
Linus Walleij <linus.walleij@linaro.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
linux-arm-kernel@lists.infradead.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org,
Alessandro Rubini <rubini@gnudd.com>,
Linus Walleij <linus.walleij@stericsson.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Deepak Saxena <dsaxena@linaro.org>,
devicetree-discuss@lists.ozlabs.org,
Grant Likely <grant.likely@secretlab.ca>
Subject: Re: linux-next: manual merge of the arm-soc tree with the i2c-embedded tree
Date: Tue, 17 Jul 2012 14:30:01 +0100 [thread overview]
Message-ID: <500568D9.10805@linaro.org> (raw)
In-Reply-To: <20120717130650.GB27595@sirena.org.uk>
On 17/07/12 14:06, Mark Brown wrote:
> On Mon, Jul 16, 2012 at 12:31:08PM +0100, Lee Jones wrote:
>
>> I agree with what you say to some extent, but I believe that it is
>> more important to have a working solution now than to ensure that
>> each bindings are as unique as possible. After any suggestion of
>> consolidation, a move from vendor specific to generically defined
>> Device Tree bindings is trivial. Especially in the current stage
>> where adaptions and definitions are still fluid.
>
>> Obviously some care is taken to ensure the bindings are as generic
>> as possible, but not to the extent that will put the project back
>> some months. Over past few months I have enabled many sub-systems;
>
> It's not just about having generic bindings, it's also about having
> bindings which have some abstraction and hope of reusability. An awful
> lot of bindings are just straight dumps of Linux data structures into
> the device tree which don't make a terribly great deal of sense as
> bindings.
The Device Tree should supply any platform configuration which the
driver needs in order to correctly setup for a particular machine. This
is exactly what the platform_data structure did before, hence is is
reasonable to assume that whatever information resides in that structure
would be required in the Device Tree.
>> however, I think it would have been a fraction of that if we'd gone
>> through the laborious process of immediate forced consolidation. I
>> think it's fine to have platform/vendor specific bindings that work,
>> then come back to unify them once the dust settles.
>
> In many of these cases we'd be better off just not putting things into
> the device tree in the first place, leaving things at the basic "is the
> device there" stuff.
Then what do you do with the platform data?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2012-07-17 13:30 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120710164130.f38e4d1673f925ddb13914c9@canb.auug.org.au>
[not found] ` <20120712131231.GH2194@pengutronix.de>
[not found] ` <20120712131231.GH2194-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-14 21:34 ` linux-next: manual merge of the arm-soc tree with the i2c-embedded tree Linus Walleij
2012-07-16 10:17 ` Wolfram Sang
2012-07-16 11:31 ` Lee Jones
2012-07-16 13:00 ` Wolfram Sang
2012-07-16 13:55 ` Lee Jones
2012-07-17 13:06 ` Mark Brown
2012-07-17 13:30 ` Lee Jones [this message]
2012-07-17 13:35 ` Mark Brown
2012-07-17 14:02 ` Lee Jones
2012-07-17 14:22 ` Mark Brown
2012-07-17 14:52 ` Lee Jones
[not found] ` <50057C1A.80606-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-07-17 15:20 ` Mark Brown
2012-07-18 5:33 ` Shawn Guo
2012-07-18 9:59 ` Mark Brown
2012-07-18 10:29 ` Lee Jones
2012-07-18 10:33 ` Mark Brown
2012-07-18 10:43 ` Lee Jones
2012-07-18 7:35 ` Lee Jones
2012-07-18 11:12 ` Mark Brown
2012-07-18 11:24 ` Lee Jones
2012-07-16 11:37 ` Linus Walleij
2012-07-16 12:35 ` Wolfram Sang
[not found] ` <20120716123550.GE17435-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-16 19:45 ` Linus Walleij
[not found] ` <CACRpkdaMB-n7XYcxE8QtAm-WrGc2DR0krfTjQZCbvOL1HYep1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-07-16 20:04 ` Chris Ball
2012-07-17 13:10 ` Mark Brown
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=500568D9.10805@linaro.org \
--to=lee.jones@linaro.org \
--cc=arnd@arndb.de \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dsaxena@linaro.org \
--cc=grant.likely@secretlab.ca \
--cc=linus.walleij@linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=olof@lixom.net \
--cc=rubini@gnudd.com \
--cc=sfr@canb.auug.org.au \
--cc=swarren@wwwdotorg.org \
--cc=w.sang@pengutronix.de \
/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).