On Sat, 16 Mar 2019 16:09:36 +0530 Karuna Grewal <karunagrewal98@xxxxxxxxx> wrote: > Hello, > > I'm interested in working on the AD7292 driver for Linux kernel as a > part of the GSoC project. I've previous experience working with device > drivers and am also familiar with couple of Linux kernel's subsystems. > For a starting point I wonder if someone can point out some tasks > which I could work upon as the project page doesn't elaborate much > about it. > In case the idea is to start working on the driver itself I'd like to > discuss about the same. > > Best Regards, > Karuna Grewal Hi Karuna and welcome to IIO. I have nothing (directly) to do with the GSOC projects, but I'm always happy to suggest tasks to anyone ;) Obviously I don't know how 'in depth' you would like, but a couple of immediate thoughts come to mind. We have been trying to remove all direct use of the mlock mutex in struct iio_dev from drivers. It has one very specific and tightly defined purpose to protect drivers from trying to do things they shouldn't when changing from a polled mode to one which is interrupt driven (DIRECT to BUFFERED). Unfortunately we weren't great at enforcing the distinction in the early days of IIO. The solution is almost always to replace the use of mlock with either calls to iio_claim_direct_mode (if it is an open coded version of what the mlock is intended for) or to introduce a lock within the driver itself with well defined scope covering whatever mlock was incorrectly being used for. Another traditional area for people first getting involved in IIO is to look at the drivers that are still in drivers/staging/iio but to be honest there are not many left there now so that isn't as fruitful as it used to be. If you do want to look at those, do send a message to the list to confirm no one else is currently looking a the same driver. Also very useful if you are going to be looking at IIO drivers is to get yourself setup with a suitable test board and any random cheap sensor (dx.com and similar are very cheap if rather slow). That way you will have verified your buses and similar before trying to start work on a new sensor. Far too much time gets wasted trying to get a device to talk, just to discover something is wrong in the platform setup and nothing is going out on the wires. If you want more suggestions, feel free to ask. Jonathan
