linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: 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

  reply	other threads:[~2012-07-17 13:30 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-10  6:41 linux-next: manual merge of the arm-soc tree with the i2c-embedded tree Stephen Rothwell
2012-07-10  6:50 ` Stephen Rothwell
2012-07-10  8:38 ` Wolfram Sang
2012-07-12 13:12 ` Wolfram Sang
2012-07-12 15:54   ` Arnd Bergmann
2012-07-13 11:03     ` Lee Jones
2012-07-14 21:34   ` 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
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
2012-07-16 19:45           ` Linus Walleij
2012-07-16 20:04             ` Chris Ball
2012-07-17 13:10           ` Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2012-07-19  5:28 Stephen Rothwell
2012-09-13  6:41 Stephen Rothwell
2012-09-13  7:09 ` Uwe Kleine-König
2012-11-15  5:27 Stephen Rothwell

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=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).