Re: [PATCH v1 5/7] iio: adc: ad4170: Add GPIO controller support

[Marcelo Schmitt <marcelo.schmitt1@gmail.com>]

...
> > +static int ad4170_gpio_get_direction(struct gpio_chip *gc, unsigned int
> > offset)
> > +{
> > +	struct iio_dev *indio_dev = gpiochip_get_data(gc);
> > +	struct ad4170_state *st = iio_priv(indio_dev);
> > +	unsigned int val;
> > +	int ret;
> > +
> > +	if (!iio_device_claim_direct(indio_dev))
> > +		return -EBUSY;
> > +
> 
> This claim_direct() makes me wonder if there's any overlap between the GPIO func
> and normal readings? Like, imagine a consumer requests a gpio and no buffering
> is happening so all is good. However, there's nothing stopping us for enabling
> buffering afterwards, right? Wouldn't that be an issue? If there are shared
> pins, I can see this also being an issue even for single shot reading...
> Otherwise, I wonder why we have this iio_device_claim_direct() calls? Is it just
> for using the internal IIO lock?

We need read/write to AD4170 registers to configure/set/read GPIOs so the intent
of claiming direct mode here is to avoid that from happening while we are doing
something else (e.g. a buffered capture). I'm now considering to also lock on the
state mutex to prevent concurrent run with the single-shot read routine.

Thanks,
Marcelo