[RFC] Make the devm_iio_device_alloc call set iio_dev.dev.parent.

[RFC] Make the devm_iio_device_alloc call set iio_dev.dev.parent.

[Jonathan Cameron]

Hi All,

One thing that I discovered via a recent input device review is that
the equivalent of our devm_iio_device_alloc there also sets the
dev.parent.

Should we do the same in IIO?

I'm a bit in too minds as it feels like it is only sort of 'part of the
allocation'.

Still it drops one line from nearly every IIO driver.
Could do the same for dev_iio_trigger_alloc as well I guess for double
savings.

Anyhow, a little cleanup that seemed like a moderately good idea to
me so I thought I'd see what the general view was.

Jonathan

Re: [RFC] Make the devm_iio_device_alloc call set iio_dev.dev.parent.

[Jonathan Cameron]

On 04/05/16 11:56, Jonathan Cameron wrote:
> Hi All,
> 
> One thing that I discovered via a recent input device review is that
> the equivalent of our devm_iio_device_alloc there also sets the
> dev.parent.
> 
> Should we do the same in IIO?
> 
> I'm a bit in too minds as it feels like it is only sort of 'part of the
> allocation'.
> 
> Still it drops one line from nearly every IIO driver.
> Could do the same for dev_iio_trigger_alloc as well I guess for double
> savings.
> 
> Anyhow, a little cleanup that seemed like a moderately good idea to
> me so I thought I'd see what the general view was.
> 
> Jonathan

I'm gong ahead with this - just for reference purposes the oddities so far
are:
stx104 which never set the parent.
max30100 which never sets the parent.
apds9960 which never sets the parent.
ms5611_i2c never sets the parent.
pulsed_light lidar never sets the parent.

lm3533 which sets the iio device parent to the mfd device parent, but allocates
on the devm against the mfd. I'm not certain this is how it should have been done
but now it is abi so we have to cope with it.
We can handle this just fine by letting it override the default.

Each patch is simple enough I'll probably just do this in one or two mega patches
rather than one per driver...

Same trick applies for the devm_iio_trigger_alloc though that is used rather less.

Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC] Make the devm_iio_device_alloc call set iio_dev.dev.parent.

[Matt Ranostay]

On Sun, May 15, 2016 at 10:55 AM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 04/05/16 11:56, Jonathan Cameron wrote:
>> Hi All,
>>
>> One thing that I discovered via a recent input device review is that
>> the equivalent of our devm_iio_device_alloc there also sets the
>> dev.parent.
>>
>> Should we do the same in IIO?
>>
>> I'm a bit in too minds as it feels like it is only sort of 'part of the
>> allocation'.
>>
>> Still it drops one line from nearly every IIO driver.
>> Could do the same for dev_iio_trigger_alloc as well I guess for double
>> savings.
>>
>> Anyhow, a little cleanup that seemed like a moderately good idea to
>> me so I thought I'd see what the general view was.
>>
>> Jonathan
>
> I'm gong ahead with this - just for reference purposes the oddities so far
> are:
> stx104 which never set the parent.
> max30100 which never sets the parent.
> apds9960 which never sets the parent.
> ms5611_i2c never sets the parent.
> pulsed_light lidar never sets the parent.

Yike! I caused 3 odd drivers here :)

>
> lm3533 which sets the iio device parent to the mfd device parent, but allocates
> on the devm against the mfd. I'm not certain this is how it should have been done
> but now it is abi so we have to cope with it.
> We can handle this just fine by letting it override the default.
>
> Each patch is simple enough I'll probably just do this in one or two mega patches
> rather than one per driver...
>
> Same trick applies for the devm_iio_trigger_alloc though that is used rather less.
>
> Jonathan
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>