Re: IIO staging TODO

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

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