On 04/17/2016 11:56 PM, Alison Schofield wrote: > On Sun, Apr 17, 2016 at 01:07:52PM -0500, Andrew F. Davis wrote: >> On 04/16/2016 02:22 PM, Jonathan Cameron wrote: >>> On 10/04/16 20:07, Alison Schofield wrote: >>>> Driver includes struct regmap and struct device in its global data. >>>> Remove the struct device and use regmap API to retrieve device info. >>>> >> >> Why? This adds nothing but more code to get dev through some >> container_of trickery when we could just keep a dev pointer in the data >> structure. >> >> Andrew > > Thanks for the review and response. The why would be for > simplification and uniformity across IIO. > I'm all for simplification and uniformity but I think this will take us in the wrong direction, a lot drivers do not use regmap for instance and so will need another method to lookup the device struct. > I think I see your point in general, but not sure I get your > specific concerns with these afe4403/04 drivers. > > The drivers only use the device struct in probe and then > again at device remove time. At probe, the change no > longer stores it in the global data. At remove the > regmap_get_device() func is a simple dereference to retrieve > the device struct. That's the simplification: we don't carry > that ptr in global data waiting for the opportunity to use it > at device remove. We just find it when we need it at device > remove. A lot of what drivers store in their per-instance data structure is only held for use in remove. Using afe4404 as an example trig and irq are also only stored for removal. A good driver framework will pass in relevant information to the driver callbacks, and so instance data structures have gotten very small, for afe4404 only regmap and regulator are actually used during runtime currently. The direction that would really be of best simplification would be to remove the need for the remove function from these drivers, if iio_trigger_register and iio_triggered_buffer_setup had devm_ versions (like most other setup functions) everything would automatically be cleaned up properly without needing a remove function. Then I would have no problem removing the unused device structure pointer, but for now their will never be a simpler trick to getting the device pointer than simply storing it in the instance data. > (Perhaps these devices are getting removed frequently?) > Quite the opposite, same for many drivers, the remove path is dangerously untested in the real world, even more reason it's nice to not need remove and let devm_ cleanup for us :) Thanks, Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
