From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lee Jones 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 Message-ID: <50057058.2060002@linaro.org> References: <5003FB7C.4030509@linaro.org> <20120717130650.GB27595@sirena.org.uk> <500568D9.10805@linaro.org> <20120717133550.GC4477@opensource.wolfsonmicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20120717133550.GC4477@opensource.wolfsonmicro.com> Sender: linux-next-owner@vger.kernel.org To: Mark Brown Cc: Wolfram Sang , Linus Walleij , Stephen Rothwell , Olof Johansson , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Alessandro Rubini , Linus Walleij , Stephen Warren , Deepak Saxena , devicetree-discuss@lists.ozlabs.org, Grant Likely List-Id: devicetree@vger.kernel.org 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 aw= ful >>> lot of bindings are just straight dumps of Linux data structures in= to >>> 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_ no= t=20 to put anything in there (platform data or Device Tree), which does not= =20 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=20 properties proposed here are platform specific. What we're discussing i= s=20 some consolidation of property names, which I do support in theory. Wha= t=20 I fear is that this driver will lack Device Tree functionality for yet=20 another kernel version if it isn't resolved quickly. Wolfram, are you theorising about these the multiple use of these=20 properties, or do you have some examples? I think we would do well to=20 work on these, or else they're just going to lie dormant and not get do= ne. --=20 Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org =E2=94=82 Open source software for ARM SoCs =46ollow Linaro: Facebook | Twitter | Blog