| Message ID | 1384562167-14725-2-git-send-email-tony@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> Since we still need to rely on a mix of device tree initialized > drivers and legacy platform data initialize drivers, let's fix > the passing of platform data to twl4030-gpio. > > As the twl4030 GPIO is initialized by twl-core.c, we need to register > the auxdata for twl4030 GPIO in twl-core.c. > > Cc: Samuel Ortiz <sameo@linux.intel.com> > Cc: Lee Jones <lee.jones@linaro.org> > Signed-off-by: Tony Lindgren <tony@atomide.com> > --- > > Samuel & Lee, I'd like to merge this fix via arm-soc tree if this looks > OK to you as I have other patches that depend on this. > > --- > drivers/mfd/twl-core.c | 15 ++++++++++++--- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index 29473c2..d5b3dd8 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -1133,6 +1133,11 @@ static int twl_remove(struct i2c_client *client) > return 0; > } > > +static struct of_dev_auxdata twl_auxdata_lookup[] = { > + OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL), > + { /* sentinel */ }, > +}; > + > /* NOTE: This driver only handles a single twl4030/tps659x0 chip */ > static int > twl_probe(struct i2c_client *client, const struct i2c_device_id *id) > @@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id) > twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1); > } > > - if (node) > - status = of_platform_populate(node, NULL, NULL, &client->dev); > - else > + if (node) { > + if (pdata) > + twl_auxdata_lookup[0].platform_data = pdata->gpio; > + status = of_platform_populate(node, NULL, twl_auxdata_lookup, > + &client->dev); > + } else { > status = add_children(pdata, irq_base, id->driver_data); Why doesn't the TWL driver use the MFD framework for this stuff? > + } > > fail: > if (status < 0)
Hi, On Mon, Nov 18, 2013 at 10:29:07AM +0000, Lee Jones wrote: > > Since we still need to rely on a mix of device tree initialized > > drivers and legacy platform data initialize drivers, let's fix > > the passing of platform data to twl4030-gpio. > > > > As the twl4030 GPIO is initialized by twl-core.c, we need to register > > the auxdata for twl4030 GPIO in twl-core.c. > > > > Cc: Samuel Ortiz <sameo@linux.intel.com> > > Cc: Lee Jones <lee.jones@linaro.org> > > Signed-off-by: Tony Lindgren <tony@atomide.com> > > --- > > > > Samuel & Lee, I'd like to merge this fix via arm-soc tree if this looks > > OK to you as I have other patches that depend on this. > > > > --- > > drivers/mfd/twl-core.c | 15 ++++++++++++--- > > 1 file changed, 12 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > > index 29473c2..d5b3dd8 100644 > > --- a/drivers/mfd/twl-core.c > > +++ b/drivers/mfd/twl-core.c > > @@ -1133,6 +1133,11 @@ static int twl_remove(struct i2c_client *client) > > return 0; > > } > > > > +static struct of_dev_auxdata twl_auxdata_lookup[] = { > > + OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL), > > + { /* sentinel */ }, > > +}; > > + > > /* NOTE: This driver only handles a single twl4030/tps659x0 chip */ > > static int > > twl_probe(struct i2c_client *client, const struct i2c_device_id *id) > > @@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id) > > twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1); > > } > > > > - if (node) > > - status = of_platform_populate(node, NULL, NULL, &client->dev); > > - else > > + if (node) { > > + if (pdata) > > + twl_auxdata_lookup[0].platform_data = pdata->gpio; > > + status = of_platform_populate(node, NULL, twl_auxdata_lookup, > > + &client->dev); > > + } else { > > status = add_children(pdata, irq_base, id->driver_data); > > Why doesn't the TWL driver use the MFD framework for this stuff? that's reminiscent from years ago and, surely, needs to be fixed. Should we gate $subject for that, though ? This has been in tree for quite a few years already and Tony's patch is still a step forward, since most omap3 platforms would break on DT-only without it. There are quite a few folks who could volunteer to fixing that after Tony's patch is in (me included, although there could be better choices hehe). cheers
> > > +static struct of_dev_auxdata twl_auxdata_lookup[] = { > > > + OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL), > > > + { /* sentinel */ }, > > > +}; > > > + > > > /* NOTE: This driver only handles a single twl4030/tps659x0 chip */ > > > static int > > > twl_probe(struct i2c_client *client, const struct i2c_device_id *id) > > > @@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id) > > > twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1); > > > } > > > > > > - if (node) > > > - status = of_platform_populate(node, NULL, NULL, &client->dev); > > > - else > > > + if (node) { > > > + if (pdata) > > > + twl_auxdata_lookup[0].platform_data = pdata->gpio; > > > + status = of_platform_populate(node, NULL, twl_auxdata_lookup, > > > + &client->dev); > > > + } else { > > > status = add_children(pdata, irq_base, id->driver_data); > > > > Why doesn't the TWL driver use the MFD framework for this stuff? > > that's reminiscent from years ago and, surely, needs to be fixed. Should > we gate $subject for that, though ? This has been in tree for quite a > few years already and Tony's patch is still a step forward, since most > omap3 platforms would break on DT-only without it. I didn't say that I would reject the patch. I was just surprised to see so much hand-rolling, as the MFD core code does much of it automatically. This is the first time I've taken a look at this and it seems to be quite the relic. > There are quite a few folks who could volunteer to fixing that after > Tony's patch is in (me included, although there could be better choices > hehe). Well it's not doing any harm. I'll make a note to fix it myself if a) no one has done so already and b) I manage to find some spare time. The latter issue is less likely to be resolved. :) Are you Acking this patch by the way?
* Lee Jones <lee.jones@linaro.org> [131118 09:47]: > > > > +static struct of_dev_auxdata twl_auxdata_lookup[] = { > > > > + OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL), > > > > + { /* sentinel */ }, > > > > +}; > > > > + > > > > /* NOTE: This driver only handles a single twl4030/tps659x0 chip */ > > > > static int > > > > twl_probe(struct i2c_client *client, const struct i2c_device_id *id) > > > > @@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id) > > > > twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1); > > > > } > > > > > > > > - if (node) > > > > - status = of_platform_populate(node, NULL, NULL, &client->dev); > > > > - else > > > > + if (node) { > > > > + if (pdata) > > > > + twl_auxdata_lookup[0].platform_data = pdata->gpio; > > > > + status = of_platform_populate(node, NULL, twl_auxdata_lookup, > > > > + &client->dev); > > > > + } else { > > > > status = add_children(pdata, irq_base, id->driver_data); > > > > > > Why doesn't the TWL driver use the MFD framework for this stuff? > > > > that's reminiscent from years ago and, surely, needs to be fixed. Should > > we gate $subject for that, though ? This has been in tree for quite a > > few years already and Tony's patch is still a step forward, since most > > omap3 platforms would break on DT-only without it. > > I didn't say that I would reject the patch. I was just surprised to > see so much hand-rolling, as the MFD core code does much of it > automatically. This is the first time I've taken a look at this and it > seems to be quite the relic. Yeah it seems something from the early days of MFD code. Then grepping for add_children shows that drivers/mfd/dm355evm_msp.c is doing it too, which should also be fixed while at it. > > There are quite a few folks who could volunteer to fixing that after > > Tony's patch is in (me included, although there could be better choices > > hehe). > > Well it's not doing any harm. I'll make a note to fix it myself if a) > no one has done so already and b) I manage to find some spare > time. The latter issue is less likely to be resolved. :) Sounds like Felipe has already picked it up for future work :) > Are you Acking this patch by the way? If this looks acceptable to you guys, I'd like to merge this via my fixes branch this week with your acks if that works for you. That way I can base my omap legacy platform data removal patches on my fixes branch while keep things working for the drivers. Alternatively I can naturally base my legacy data removal on -rc2 too if this gets merged to mainline by then via the MFD tree. Regards, Tony
Hi, On Mon, Nov 18, 2013 at 05:46:38PM +0000, Lee Jones wrote: > > > > +static struct of_dev_auxdata twl_auxdata_lookup[] = { > > > > + OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL), > > > > + { /* sentinel */ }, > > > > +}; > > > > + > > > > /* NOTE: This driver only handles a single twl4030/tps659x0 chip */ > > > > static int > > > > twl_probe(struct i2c_client *client, const struct i2c_device_id *id) > > > > @@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id) > > > > twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1); > > > > } > > > > > > > > - if (node) > > > > - status = of_platform_populate(node, NULL, NULL, &client->dev); > > > > - else > > > > + if (node) { > > > > + if (pdata) > > > > + twl_auxdata_lookup[0].platform_data = pdata->gpio; > > > > + status = of_platform_populate(node, NULL, twl_auxdata_lookup, > > > > + &client->dev); > > > > + } else { > > > > status = add_children(pdata, irq_base, id->driver_data); > > > > > > Why doesn't the TWL driver use the MFD framework for this stuff? > > > > that's reminiscent from years ago and, surely, needs to be fixed. Should > > we gate $subject for that, though ? This has been in tree for quite a > > few years already and Tony's patch is still a step forward, since most > > omap3 platforms would break on DT-only without it. > > I didn't say that I would reject the patch. I was just surprised to > see so much hand-rolling, as the MFD core code does much of it > automatically. This is the first time I've taken a look at this and it > seems to be quite the relic. alright, thanks for confirming. > > There are quite a few folks who could volunteer to fixing that after > > Tony's patch is in (me included, although there could be better choices > > hehe). > > Well it's not doing any harm. I'll make a note to fix it myself if a) > no one has done so already and b) I manage to find some spare > time. The latter issue is less likely to be resolved. :) > > Are you Acking this patch by the way? sure: Acked-by: Felipe Balbi <balbi@ti.com>
> > Are you Acking this patch by the way? > > If this looks acceptable to you guys, I'd like to merge this via my fixes > branch this week with your acks if that works for you. That way I can base > my omap legacy platform data removal patches on my fixes branch while keep > things working for the drivers. Alternatively I can naturally base my > legacy data removal on -rc2 too if this gets merged to mainline by then > via the MFD tree. I can either send it up for the -rcs, or I can create an immutable branch for you to pull from. That way the patch can do in via ARM-SoC and MFD and we can let Git sort it out.
* Lee Jones <lee.jones@linaro.org> [131118 11:10]: > > > Are you Acking this patch by the way? > > > > If this looks acceptable to you guys, I'd like to merge this via my fixes > > branch this week with your acks if that works for you. That way I can base > > my omap legacy platform data removal patches on my fixes branch while keep > > things working for the drivers. Alternatively I can naturally base my > > legacy data removal on -rc2 too if this gets merged to mainline by then > > via the MFD tree. > > I can either send it up for the -rcs, or I can create an immutable > branch for you to pull from. That way the patch can do in via ARM-SoC > and MFD and we can let Git sort it out. OK great, I'd prefer an immutable branch that I can merge in too. Then you can bundle it with other MFD fixes for the -rc series and send it in when it suits you :) Regards, Tony
On Mon, 18 Nov 2013, Tony Lindgren wrote: > * Lee Jones <lee.jones@linaro.org> [131118 11:10]: > > > > Are you Acking this patch by the way? > > > > > > If this looks acceptable to you guys, I'd like to merge this via my fixes > > > branch this week with your acks if that works for you. That way I can base > > > my omap legacy platform data removal patches on my fixes branch while keep > > > things working for the drivers. Alternatively I can naturally base my > > > legacy data removal on -rc2 too if this gets merged to mainline by then > > > via the MFD tree. > > > > I can either send it up for the -rcs, or I can create an immutable > > branch for you to pull from. That way the patch can do in via ARM-SoC > > and MFD and we can let Git sort it out. > > OK great, I'd prefer an immutable branch that I can merge in too. Then > you can bundle it with other MFD fixes for the -rc series and send it > in when it suits you :) That's fine. It's 19:30 here now and I still have a shed load of debugging to do, so I'll deal with this tomorrow if it's all the same to you?
* Lee Jones <lee.jones@linaro.org> [131118 11:29]: > On Mon, 18 Nov 2013, Tony Lindgren wrote: > > > * Lee Jones <lee.jones@linaro.org> [131118 11:10]: > > > > > Are you Acking this patch by the way? > > > > > > > > If this looks acceptable to you guys, I'd like to merge this via my fixes > > > > branch this week with your acks if that works for you. That way I can base > > > > my omap legacy platform data removal patches on my fixes branch while keep > > > > things working for the drivers. Alternatively I can naturally base my > > > > legacy data removal on -rc2 too if this gets merged to mainline by then > > > > via the MFD tree. > > > > > > I can either send it up for the -rcs, or I can create an immutable > > > branch for you to pull from. That way the patch can do in via ARM-SoC > > > and MFD and we can let Git sort it out. > > > > OK great, I'd prefer an immutable branch that I can merge in too. Then > > you can bundle it with other MFD fixes for the -rc series and send it > > in when it suits you :) > > That's fine. It's 19:30 here now and I still have a shed load of > debugging to do, so I'll deal with this tomorrow if it's all the same > to you? Yeah sure I can wait few days no problem. Thanks, Tony
On Mon, 18 Nov 2013, Tony Lindgren wrote: > * Lee Jones <lee.jones@linaro.org> [131118 11:10]: > > > > Are you Acking this patch by the way? > > > > > > If this looks acceptable to you guys, I'd like to merge this via my fixes > > > branch this week with your acks if that works for you. That way I can base > > > my omap legacy platform data removal patches on my fixes branch while keep > > > things working for the drivers. Alternatively I can naturally base my > > > legacy data removal on -rc2 too if this gets merged to mainline by then > > > via the MFD tree. > > > > I can either send it up for the -rcs, or I can create an immutable > > branch for you to pull from. That way the patch can do in via ARM-SoC > > and MFD and we can let Git sort it out. > > OK great, I'd prefer an immutable branch that I can merge in too. Then > you can bundle it with other MFD fixes for the -rc series and send it > in when it suits you :) https://git.linaro.org/gitweb?p=people/ljones/mfd.git;a=shortlog;h=refs/heads/for-mfd-fixes Here Tony, you can take this one. I will simply apply my other fixes on top of it. The issue is, I will most likely have to rebase it on top of -rc1 prior to sending a request to Linus, so in that regard it's not exactly immutable.
* Lee Jones <lee.jones@linaro.org> [131121 03:10]: > > Here Tony, you can take this one. > > > > I will simply apply my other fixes on top of it. > > > > The issue is, I will most likely have to rebase it on top of -rc1 prior > > to sending a request to Linus, so in that regard it's not exactly > > immutable. > > > > Ignore the above. This is what you want: Thanks, I'll use that commit in my omap-for-v3.14/board-removal branch. Regards, Tony > The following changes since commit 5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52: > > Linux 3.12 (2013-11-03 15:41:51 -0800) > > are available in the git repository at: > > git://git.linaro.org/people/ljones/mfd.git tags/ib-tony > > for you to fetch changes up to f984370913d3ba5d13806cc8ac6fc26f8ebd1694: > > mfd: twl-core: Fix passing of platform data in the device tree case (2013-11-21 10:42:36 +0000) > > ---------------------------------------------------------------- > warning: refname 'ib-tony' is ambiguous. > Immutable branch for Tony Lindgren > > ---------------------------------------------------------------- > Tony Lindgren (1): > mfd: twl-core: Fix passing of platform data in the device tree case > > drivers/mfd/twl-core.c | 15 ++++++++++++--- > 1 file changed, 12 insertions(+), 3 deletions(-) > > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead > Linaro.org ? Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 29473c2..d5b3dd8 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -1133,6 +1133,11 @@ static int twl_remove(struct i2c_client *client) return 0; } +static struct of_dev_auxdata twl_auxdata_lookup[] = { + OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL), + { /* sentinel */ }, +}; + /* NOTE: This driver only handles a single twl4030/tps659x0 chip */ static int twl_probe(struct i2c_client *client, const struct i2c_device_id *id) @@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id) twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1); } - if (node) - status = of_platform_populate(node, NULL, NULL, &client->dev); - else + if (node) { + if (pdata) + twl_auxdata_lookup[0].platform_data = pdata->gpio; + status = of_platform_populate(node, NULL, twl_auxdata_lookup, + &client->dev); + } else { status = add_children(pdata, irq_base, id->driver_data); + } fail: if (status < 0)
Since we still need to rely on a mix of device tree initialized drivers and legacy platform data initialize drivers, let's fix the passing of platform data to twl4030-gpio. As the twl4030 GPIO is initialized by twl-core.c, we need to register the auxdata for twl4030 GPIO in twl-core.c. Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Lee Jones <lee.jones@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> --- Samuel & Lee, I'd like to merge this fix via arm-soc tree if this looks OK to you as I have other patches that depend on this. --- drivers/mfd/twl-core.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)