Re: [PATCH v2 4/5] iio: health: afe4404: use regmap to retrieve struct device

[Andrew F. Davis]

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