Apologies for the delayed response. On Sun, Mar 17, 2019 at 12:43 AM Jonathan Cameron <jic23@xxxxxxxxxxxxxxxxxxxxx> wrote: > 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. Thanks for your suggestions. I'd tried this staging driver cleanup long time back and I didn't find much of the cleanup patches. So, preferably I'll go ahead with the former suggestion on "removal of mlock_mutex". Meanwhile, I'll get started with testing this on a sensor as well. I'll get back to you with any doubts while working on these. Regards, Karuna
