[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120717142222.GE4477@opensource.wolfsonmicro.com>
Date: Tue, 17 Jul 2012 15:22:22 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Lee Jones <lee.jones@...aro.org>
Cc: Wolfram Sang <w.sang@...gutronix.de>,
Linus Walleij <linus.walleij@...aro.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>,
linux-arm-kernel@...ts.infradead.org, linux-next@...r.kernel.org,
linux-kernel@...r.kernel.org, Alessandro Rubini <rubini@...dd.com>,
Linus Walleij <linus.walleij@...ricsson.com>,
Stephen Warren <swarren@...dotorg.org>,
Deepak Saxena <dsaxena@...aro.org>,
devicetree-discuss@...ts.ozlabs.org,
Grant Likely <grant.likely@...retlab.ca>
Subject: Re: linux-next: manual merge of the arm-soc tree with the
i2c-embedded tree
On Tue, Jul 17, 2012 at 03:02:00PM +0100, Lee Jones wrote:
> I'm sure sure this is relevant in the current case though, as the
> i2c properties proposed here are platform specific. What we're
I've not seen the specific example (though fankly it seems quite
surprising that there's anything other than bus speed that the platform
might want to configure for I2C...).
> 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.
Well, if checking the DT checky box is the important thing then just
adding an of_match_table ought to be enough? It's fairly common for
platform data to have lots of stuff that's not used by most systems
so you can often cover 90% of systems with a very small subset of the
configurability.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists