devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 15:02:00 +0100	[thread overview]
Message-ID: <50057058.2060002@linaro.org> (raw)
In-Reply-To: <20120717133550.GC4477@opensource.wolfsonmicro.com>

On 17/07/12 14:35, Mark Brown wrote:
> On Tue, Jul 17, 2012 at 02:30:01PM +0100, Lee Jones wrote:
>> On 17/07/12 14:06, Mark Brown wrote:
>
>>> 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.
>
> An *awful* lot of what people are trying to put into platform data is
> nothing to do with that, it's just the generic data the driver needs to
> be able to understand the hardware at all.  Things like the MFD
> breakdown, random parameters of the hardware which you can infer from
> the device name and so on.

I can only speak from a personal perspective on that one. I do _try_ not 
to put anything in there (platform data or Device Tree), which does not 
belong. I have no idea how successful that notion was however.

I'm sure sure this is relevant in the current case though, as the i2c 
properties proposed here are platform specific. What we're discussing is 
some consolidation of property names, which I do support in theory. What 
I fear is that this driver will lack Device Tree functionality for yet 
another kernel version if it isn't resolved quickly.

Wolfram, are you theorising about these the multiple use of these 
properties, or do you have some examples? I think we would do well to 
work on these, or else they're just going to lie dormant and not get done.

-- 
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 14:02 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
2012-07-17 13:35               ` Mark Brown
2012-07-17 14:02                 ` Lee Jones [this message]
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=50057058.2060002@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).