On Sun, 23 Feb 2020 14:36:09 +0530 Rohit Sarkar <rohitsarkar5398@xxxxxxxxx> 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
