Re: [PATCH][RFC] iio: core: add a class hierarchy on iio device lock

From: Lars-Peter Clausen
Date: Tue Oct 15 2019 - 17:39:17 EST

On 10/14/19 5:59 PM, Olivier MOYSAN wrote:
> Hello Jonathan,
> Thanks for your comment.
> On 10/12/19 10:57 AM, Jonathan Cameron wrote:
>> On Fri, 11 Oct 2019 17:13:14 +0200
>> Olivier Moysan <olivier.moysan@xxxxxx> wrote:
>>> The aim of this patch is to correct a recursive locking warning,
>>> detected when setting CONFIG_PROVE_LOCKING flag (as shown in message below).
>>> This message was initially triggered by the following call sequence
>>> in stm32-dfsdm-adc.c driver, when using IIO hardware consumer interface.
>>> in stm32_dfsdm_read_raw()
>>> iio_device_claim_direct_mode
>>> mutex_lock(&indio_dev->mlock); -> lock on dfsdm device
>>> iio_hw_consumer_enable
>>> iio_update_buffers
>>> mutex_lock(&indio_dev->mlock); -> lock on hw consumer device
>> Hmm. I'm not sure I follow the logic. That lock is
>> for one thing and one thing only, preventing access
>> to the iio device that are unsafe when it is running
>> in a buffered mode. We shouldn't be in a position where
>> we both say don't do this if we are in buffered mode, + enter
>> buffered mode whilst doing this, or we need special functions
>> for entering buffering mode if in this state. We are in
>> some sense combining internal driver logic with overall
>> IIO states. IIO shouldn't care that the device is using
>> the same methods under the hood for buffered and non
>> buffered operations.
>> I can't really recall how this driver works. Is it actually
>> possible to have multiple hw_consumers at the same time?
>> So do we end up with multiple buffers registered and have
>> to demux out to the read_raw + the actual buffered path?
>> Given we have a bit of code saying grab one sample, I'm
>> going to guess we don't...
>> If so, the vast majority of the buffer setup code in IIO
>> is irrelevant here and we just need to call a few of
>> the callbacks from this driver directly... (I think
>> though I haven't chased through every corner.
>> I'd rather avoid introducing this nesting for a corner
>> case that makes no 'semantic' sense in IIO as it leaves us
>> in two separate states at the same time that the driver
>> is trying to make mutually exclusive. We can't both
>> not be in buffered mode, and in buffered mode.
>> Thanks and good luck with this nasty corner!
>> Jonathan
> Here I consider the following use case:
> A single conversion is performed. The dfsdm (filter) is chained with a
> front-end, which can be an ADC or a sensor. So we have two IIO devices,
> the dfsdm and its front-end handled through the hw consumer interface.
> You are right. There is something wrong here, in buffered/non-buffered
> mode mixing.
> iio_hw_consumer_enable() call is used to enable the front-end device.
> But this interface is intended for buffered mode.
> So this is not coherent with the expected single conversion mode,
> indeed. Another interface is required to manage the front-end device. I
> have a poor knowledge of iio framework, but it seems to me that there is
> no interface to manage this.
> My understanding regarding mlock, is that it is used to protect the
> state of the iio device.
> I we want to do a conversion from the chained devices, I think we need
> to activate the first device
> and keep it performing conversion, as long as the second device has done
> its conversion.
> We need to protect both devices, and we should have to do it in a nested
> way.
> So, I guess that anyway, nested mutexes would be required in this case.

Others like regmap have solved this by having a lockclass per instance.
Although that is not ideal either since it will slow down lockdep.