Re: [GSoC] AD7292 driver project

[Jonathan Cameron <jic23@jic23.retrosnub.co.uk>]

On Sat, 16 Mar 2019 16:09:36 +0530
Karuna Grewal <karunagrewal98@gmail.com> 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