linux-kernel - Re: [PATCH 12/19] i2c-nomadik: Register sub-devices when passed via Device Tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120914082754.GE3374@gmail.com>
Date:	Fri, 14 Sep 2012 09:27:56 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Wolfram Sang <w.sang@...gutronix.de>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	STEricsson_nomadik_linux@...t.st.com, linus.walleij@...ricsson.com,
	arnd@...db.de, linux-i2c@...r.kernel.org
Subject: Re: [PATCH 12/19] i2c-nomadik: Register sub-devices when passed via
 Device Tree

On Wed, Sep 12, 2012 at 12:52:02PM +0200, Wolfram Sang wrote:
> On Mon, Sep 10, 2012 at 04:42:36AM -0700, Linus Walleij wrote:
> > On Fri, Sep 7, 2012 at 1:14 PM, Lee Jones <lee.jones@...aro.org> wrote:
> > 
> > > Each I2C device can be correctly probed already using Device Tree,
> > > but the sub-devices still have to be registered by calls to
> > > i2c_register_board_info(). After this patch, each sub-device can
> > > be registered directly from Device Tree instead, removing the
> > > requirement for the aforementioned calls from platform code.
> > >
> > > CC: linux-i2c@...r.kernel.org
> > > CC: Wolfram Sang <w.sang@...gutronix.de>
> > > Signed-off-by: Lee Jones <lee.jones@...aro.org>
> > 
> > The patch as such is fine.
> > Acked-by: Linus Walleij <linus.walleij@...aro.org>
> > 
> > ...but there will be merge issues (of the type I'm
> > discussing with Arnd in another thread).
> > 
> > > ---
> > >  drivers/i2c/busses/i2c-nomadik.c |    4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
> > > index 5d1a970..01231c2 100644
> > > --- a/drivers/i2c/busses/i2c-nomadik.c
> > > +++ b/drivers/i2c/busses/i2c-nomadik.c
> > > @@ -26,6 +26,7 @@
> > >  #include <linux/pm_runtime.h>
> > >  #include <linux/platform_data/i2c-nomadik.h>
> > >  #include <linux/of.h>
> > > +#include <linux/of_i2c.h>
> > 
> > This is clearly dependent on the other patches to I2C to
> > be merged first (the include above is not yet there in
> > linux-next even), so this patch should go into Wolfram's
> > tree right? Else we have to rip out all the patches to the
> > I2C driver from his tree and funnel it all through ARM SoC.
> 
> First, I'd like to have this patch squashed with "i2c: nomadik: Add
> Device Tree support to the Nomadik I2C driver". I wanted to do this on
> my own, but the patches do not apply to 3.6-rc5 (with or without
> regulator removal patch from Linus)?

I'm really not keen on squashing all my patches together. They are
clearly have very different purposes. If you think they are closely
related, then pull them in sequentially, but please don't squash
all my work into a single patch for no other reason than convenience.

> I can also take the I2C related changes to the devicetrees via my tree.
> This is not uncommon. Some people prefer to do this via their soc-trees,
> though. I don't care much since this is not really a hard dependency
> causing build failures or merge conflicts, but just needs a little extra
> time until the patches are all there...

It would be better for all the Device Tree changes go in as a single
patch-set. Again, I don't care where they go, so long as they go in
together. arm-soc seems like the most generic place for them to be
pulled into though.

Kind regards,
Lee

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/