* Lee Jones <lee.jones@xxxxxxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html