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/
