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: Wed, 18 Jul 2012 08:35:21 +0100 [thread overview] Message-ID: <50066739.4010206@linaro.org> (raw) In-Reply-To: <20120717152001.GF4477@opensource.wolfsonmicro.com> On 17/07/12 16:20, Mark Brown wrote: > On Tue, Jul 17, 2012 at 03:52:10PM +0100, Lee Jones wrote: > >> I think it would be okay to take the 3 patches due for the v3.6 >> merge window, which target the nmk-i2c driver. If any consolidation >> happens in the mean-time/future I will personally do the work to >> bring the nmk-i2c into line to use any generic bindings which >> result. > >> No one else is ever going to use these vendor specific bindings, so >> I'm sure no issues will arise. It also means that we have a fully >> enabled driver which is capable of receiving a new configuration via >> minor changes to the dts, which is important for the current (only) >> user of this driver for an upcoming project. > > So, this is pretty much what vendors always say about this stuff... I agree, but in this instance it really does stand to reason. 1. No unified bindings currently exist. 2. I don't have time to create them. 3. It will probably take quite a bit of time for someone else to get round to creating them. 4. The bindings I'm proposing are siloed by vendor and driver, so will cause no harm. 5. I've already volunteered to move them over to the unified ones once created. 6. These allow support for the driver to work with DT, at the moment it does not. Personally, I think there is more to be gained by applying the (working) vendor specific bindings to the vendor specific driver until some more consolidated ones appear. > Looking at what's specified in the platform data in the current kernel > it seems like there's a mixture of things in there that are board and > silicon specific. We've got parameters like the the speed mode and > timeout which are reasonably board specific but we've also got things > like the FIFO sizes which shouldn't be at all board specific and slsu > which really looks like it's something that that the driver ought to be > able to figure out for itself. > -- 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
WARNING: multiple messages have this Message-ID (diff)
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: Wed, 18 Jul 2012 08:35:21 +0100 [thread overview] Message-ID: <50066739.4010206@linaro.org> (raw) In-Reply-To: <20120717152001.GF4477@opensource.wolfsonmicro.com> On 17/07/12 16:20, Mark Brown wrote: > On Tue, Jul 17, 2012 at 03:52:10PM +0100, Lee Jones wrote: > >> I think it would be okay to take the 3 patches due for the v3.6 >> merge window, which target the nmk-i2c driver. If any consolidation >> happens in the mean-time/future I will personally do the work to >> bring the nmk-i2c into line to use any generic bindings which >> result. > >> No one else is ever going to use these vendor specific bindings, so >> I'm sure no issues will arise. It also means that we have a fully >> enabled driver which is capable of receiving a new configuration via >> minor changes to the dts, which is important for the current (only) >> user of this driver for an upcoming project. > > So, this is pretty much what vendors always say about this stuff... I agree, but in this instance it really does stand to reason. 1. No unified bindings currently exist. 2. I don't have time to create them. 3. It will probably take quite a bit of time for someone else to get round to creating them. 4. The bindings I'm proposing are siloed by vendor and driver, so will cause no harm. 5. I've already volunteered to move them over to the unified ones once created. 6. These allow support for the driver to work with DT, at the moment it does not. Personally, I think there is more to be gained by applying the (working) vendor specific bindings to the vendor specific driver until some more consolidated ones appear. > Looking at what's specified in the platform data in the current kernel > it seems like there's a mixture of things in there that are board and > silicon specific. We've got parameters like the the speed mode and > timeout which are reasonably board specific but we've also got things > like the FIFO sizes which shouldn't be at all board specific and slsu > which really looks like it's something that that the driver ought to be > able to figure out for itself. > -- 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-18 7:35 UTC|newest] Thread overview: 80+ 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:41 ` Stephen Rothwell 2012-07-10 6:41 ` Stephen Rothwell 2012-07-10 6:50 ` Stephen Rothwell 2012-07-10 6:50 ` Stephen Rothwell 2012-07-10 6:50 ` Stephen Rothwell 2012-07-10 8:38 ` Wolfram Sang 2012-07-10 8:38 ` Wolfram Sang 2012-07-12 13:12 ` Wolfram Sang 2012-07-12 13:12 ` Wolfram Sang 2012-07-12 15:54 ` Arnd Bergmann 2012-07-12 15:54 ` Arnd Bergmann 2012-07-13 11:03 ` Lee Jones 2012-07-13 11:03 ` Lee Jones 2012-07-14 21:34 ` Linus Walleij 2012-07-14 21:34 ` Linus Walleij 2012-07-14 21:34 ` Linus Walleij 2012-07-16 10:17 ` Wolfram Sang 2012-07-16 10:17 ` Wolfram Sang 2012-07-16 11:31 ` Lee Jones 2012-07-16 11:31 ` Lee Jones 2012-07-16 13:00 ` Wolfram Sang 2012-07-16 13:00 ` Wolfram Sang 2012-07-16 13:55 ` Lee Jones 2012-07-16 13:55 ` Lee Jones 2012-07-17 13:06 ` Mark Brown 2012-07-17 13:06 ` Mark Brown 2012-07-17 13:30 ` Lee Jones 2012-07-17 13:30 ` Lee Jones 2012-07-17 13:35 ` Mark Brown 2012-07-17 13:35 ` Mark Brown 2012-07-17 14:02 ` Lee Jones 2012-07-17 14:02 ` Lee Jones 2012-07-17 14:22 ` Mark Brown 2012-07-17 14:22 ` Mark Brown 2012-07-17 14:52 ` Lee Jones 2012-07-17 14:52 ` Lee Jones 2012-07-17 15:20 ` Mark Brown 2012-07-17 15:20 ` Mark Brown 2012-07-17 15:20 ` Mark Brown 2012-07-18 5:33 ` Shawn Guo 2012-07-18 5:33 ` Shawn Guo 2012-07-18 5:33 ` Shawn Guo 2012-07-18 9:59 ` Mark Brown 2012-07-18 9:59 ` Mark Brown 2012-07-18 10:29 ` Lee Jones 2012-07-18 10:29 ` Lee Jones 2012-07-18 10:33 ` Mark Brown 2012-07-18 10:33 ` Mark Brown 2012-07-18 10:43 ` Lee Jones 2012-07-18 10:43 ` Lee Jones 2012-07-18 7:35 ` Lee Jones [this message] 2012-07-18 7:35 ` Lee Jones 2012-07-18 11:12 ` Mark Brown 2012-07-18 11:12 ` Mark Brown 2012-07-18 11:24 ` Lee Jones 2012-07-18 11:24 ` Lee Jones 2012-07-16 11:37 ` Linus Walleij 2012-07-16 11:37 ` Linus Walleij 2012-07-16 12:35 ` Wolfram Sang 2012-07-16 12:35 ` Wolfram Sang 2012-07-16 19:45 ` Linus Walleij 2012-07-16 19:45 ` Linus Walleij 2012-07-16 19:45 ` Linus Walleij 2012-07-16 20:04 ` Chris Ball 2012-07-16 20:04 ` Chris Ball 2012-07-16 20:04 ` Chris Ball 2012-07-17 13:10 ` Mark Brown 2012-07-17 13:10 ` Mark Brown 2012-07-19 5:28 Stephen Rothwell 2012-07-19 5:28 ` Stephen Rothwell 2012-07-19 5:28 ` Stephen Rothwell 2012-09-13 6:41 Stephen Rothwell 2012-09-13 6:41 ` Stephen Rothwell 2012-09-13 6:41 ` Stephen Rothwell 2012-09-13 7:09 ` Uwe Kleine-König 2012-09-13 7:09 ` Uwe Kleine-König 2012-11-15 5:27 Stephen Rothwell 2012-11-15 5:27 ` Stephen Rothwell 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=50066739.4010206@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.