On Sat, 9 Feb 2019 12:56:11 -0600 David Lechner <david@xxxxxxxxxxxxxx> wrote: > On 2/9/19 11:00 AM, Jonathan Cameron wrote: > > Nope. This is a state lock used to protect against transitions between > > different modes of the IIO device (buffered vs polled), it > > isn't suitable for general use. > > > > The driver should be modified to handle that correctly. > > We have iio_claim_direct_mode etc that deal with the case > > where a device can't do certain operations whilst in buffered > > mode. Note it can fail and should. > > > > Seems there are more drivers still doing this than I thought. > > If anyone is bored and wants to clean them out, that would be > > most appreciated! > > > > If you need locking to protect a local buffer or the device > > state, define a new lock to do it with clearly documented > > scope. > > Just as a reminder, there is a use case for this particular > chip that requires buffered mode and direct mode at the same > time. > > https://patchwork.kernel.org/patch/10539021/ > https://patchwork.kernel.org/patch/10527757/ Thanks, I had indeed forgotten that entirely. So it should have a local lock and not take mlock explicitly at all. Jonathan
