IIO staging TODO

IIO staging TODO

[Rohit Sarkar]

Hey,
I was going through the TODO in staging/iio.

"
Convert all uses of the old GPIO API from <linux/gpio.h> to the
GPIO descriptor API in <linux/gpio/consumer.h> and look up GPIO
lines from device tree, ACPI or board files, board files should
use <linux/gpio/machine.h>.
"

I couldn't find any usages of the old gpio API in iio staging. We can
probably update the TODO to remove this item.

Was wondering if there is any other TODO/ low hanging fruit in IIO?

Thanks,
Rohit

Re: IIO staging TODO

[Jonathan Cameron]

On Sun, 23 Feb 2020 14:36:09 +0530
Rohit Sarkar <rohitsarkar5398@gmail.com> wrote:

> Hey,
> I was going through the TODO in staging/iio.
> 
> "
> Convert all uses of the old GPIO API from <linux/gpio.h> to the
> GPIO descriptor API in <linux/gpio/consumer.h> and look up GPIO
> lines from device tree, ACPI or board files, board files should
> use <linux/gpio/machine.h>.
> "
> 
> I couldn't find any usages of the old gpio API in iio staging. We can
> probably update the TODO to remove this item.

Cool. Patches to the TODO welcome :) I guess the last of these got killed off.

> 
> Was wondering if there is any other TODO/ low hanging fruit in IIO?

If you want to take a look at device tree bindings there is definitely work
to be done there.

* Missing binding docs for devices that are obviously used via device tree.
* Yaml conversions of abandoned drivers. 

I'd mostly like to leave actually doing yaml conversions of actively
maintained drivers to their maintainers but I suspect we have quite a few
where no one has touched them in years.

Another area is missing ABI documentation.

Reviewing if there is anything worth keeping in drivers/staging/iio/Documentation
and putting it in the right place if so is also useful.

For code related stuff, I suspect the remaining staging drivers are still
there for a reason (often a hard problem to be resolved).

One task we often ask people to look at is uses of iio_dev->mlock.
That lock should never be used directly but we were less than careful
about it in the early days of IIO so there are still a few instances
in drivers.  My max1363 driver for example :)

Moving to either a local lock, or to using the iio_claim_direct etc
functions to manage this in a race free way tidies this bit of implementation
mess up.  It requires careful analysis of 'what' the lock is there for and
patches need to state your conclusions on that clearly so others can
verify you are correct!

One thing to note is never send too many patches of the same type out
until you have reviews back.  It's too easy to have the same issue repeated
many times over, so better to send things out slower.

Thanks and good luck,

Jonathan

> 
> Thanks,
> Rohit

Re: IIO staging TODO

[Ardelean, Alexandru]

On Mon, 2020-02-24 at 18:00 +0000, Jonathan Cameron wrote:
> On Sun, 23 Feb 2020 14:36:09 +0530
> Rohit Sarkar <rohitsarkar5398@gmail.com> wrote:
> 
> > Hey,
> > I was going through the TODO in staging/iio.
> > 
> > "
> > Convert all uses of the old GPIO API from <linux/gpio.h> to the
> > GPIO descriptor API in <linux/gpio/consumer.h> and look up GPIO
> > lines from device tree, ACPI or board files, board files should
> > use <linux/gpio/machine.h>.
> > "
> > 
> > I couldn't find any usages of the old gpio API in iio staging. We can
> > probably update the TODO to remove this item.
> 
> Cool. Patches to the TODO welcome :) I guess the last of these got killed off.
> 
> > Was wondering if there is any other TODO/ low hanging fruit in IIO?
> 
> If you want to take a look at device tree bindings there is definitely work
> to be done there.
> 
> * Missing binding docs for devices that are obviously used via device tree.
> * Yaml conversions of abandoned drivers. 
> 
> I'd mostly like to leave actually doing yaml conversions of actively
> maintained drivers to their maintainers but I suspect we have quite a few
> where no one has touched them in years.
> 
> Another area is missing ABI documentation.
> 
> Reviewing if there is anything worth keeping in
> drivers/staging/iio/Documentation
> and putting it in the right place if so is also useful.
> 
> For code related stuff, I suspect the remaining staging drivers are still
> there for a reason (often a hard problem to be resolved).
> 
> One task we often ask people to look at is uses of iio_dev->mlock.
> That lock should never be used directly but we were less than careful
> about it in the early days of IIO so there are still a few instances
> in drivers.  My max1363 driver for example :)
> 
> Moving to either a local lock, or to using the iio_claim_direct etc
> functions to manage this in a race free way tidies this bit of implementation
> mess up.  It requires careful analysis of 'what' the lock is there for and
> patches need to state your conclusions on that clearly so others can
> verify you are correct!
> 
> One thing to note is never send too many patches of the same type out
> until you have reviews back.  It's too easy to have the same issue repeated
> many times over, so better to send things out slower.
> 

I also usually add here the conversion of drivers from device-tree-centric to
the more neutral/generic property-handlers; usually it's just converting
functions "of_property_read_xxx()" to "device_property_read_xxx()"; the latter
also supports ACPI.

On the same page, there's also removing the old platform_data constructs from
drivers and converting it to state-struct and using property handlers/readers.

Usually we would just say convert platform-data to device-tree, but now I'm
trying to go a bit further and try to make things a bit more generic to also
include ACPI.

> Thanks and good luck,
> 
> Jonathan
> 
> > Thanks,
> > Rohit
> 
>