On Mon, 2020-02-24 at 18:00 +0000, Jonathan Cameron wrote: > 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. > 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 > >
