On Fri, Sep 7, 2012 at 1:14 PM, Lee Jones <lee.jones@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx > CC: Wolfram Sang <w.sang@xxxxxxxxxxxxxx> > Signed-off-by: Lee Jones <lee.jones@xxxxxxxxxx> The patch as such is fine. Acked-by: Linus Walleij <linus.walleij@xxxxxxxxxx> ...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. With the changes to the device tree itself being dependent on this, they should thus also go through the I2C tree. But they may be heavily dependent on the other DT changes you've done, so they cannot be applied to Wolfram's tree... And thus you may need to hold this change off until the I2C changes are upstream, or start creating cross-tree dependencies. Maybe I shouldn't worry about these things and just ACK stuff, but I have such problems with cross-tree merges myself so just trying to be helpful :-/ Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
