Re: [PATCH v5 1/6] iio: Add output buffer support

[Jonathan Cameron]

On Mon, 20 Sep 2021 08:02:29 +0000
"Sa, Nuno" <Nuno.Sa@xxxxxxxxxx> wrote:

> > From: Jonathan Cameron <jic23@xxxxxxxxxx>
> > Sent: Sunday, September 19, 2021 7:03 PM
> > To: Chindris, Mihail <Mihail.Chindris@xxxxxxxxxx>
> > Cc: linux-kernel@xxxxxxxxxxxxxxx; linux-iio@xxxxxxxxxxxxxxx;
> > lars@xxxxxxxxxx; Hennerich, Michael
> > <Michael.Hennerich@xxxxxxxxxx>; Sa, Nuno
> > <Nuno.Sa@xxxxxxxxxx>; Bogdan, Dragos
> > <Dragos.Bogdan@xxxxxxxxxx>; alexandru.ardelean@xxxxxxxxxx
> > Subject: Re: [PATCH v5 1/6] iio: Add output buffer support
> > 
> > On Thu, 16 Sep 2021 18:29:09 +0000
> > Mihail Chindris <mihail.chindris@xxxxxxxxxx> wrote:
> >   
> > > Currently IIO only supports buffer mode for capture devices like  
> > ADCs. Add  
> > > support for buffered mode for output devices like DACs.
> > >
> > > The output buffer implementation is analogous to the input buffer
> > > implementation. Instead of using read() to get data from the buffer  
> > write()  
> > > is used to copy data into the buffer.
> > >
> > > poll() with POLLOUT will wakeup if there is space available.
> > >
> > > Drivers can remove data from a buffer using iio_pop_from_buffer(),  
> > the  
> > > function can e.g. called from a trigger handler to write the data to
> > > hardware.
> > >
> > > A buffer can only be either a output buffer or an input, but not both.  
> > So,  
> > > for a device that has an ADC and DAC path, this will mean 2 IIO  
> > buffers  
> > > (one for each direction).
> > >
> > > The direction of the buffer is decided by the new direction field of  
> > the  
> > > iio_buffer struct and should be set after allocating and before  
> > registering  
> > > it.
> > >
> > > Signed-off-by: Lars-Peter Clausen <lars@xxxxxxxxxx>
> > > Signed-off-by: Alexandru Ardelean  
> > <alexandru.ardelean@xxxxxxxxxx>  
> > > Signed-off-by: Mihail Chindris <mihail.chindris@xxxxxxxxxx>  
> > 
> > A few minor things inline.  I would have expected the missing check
> > on insert_buffer to have resulted in a nasty deference of a null pointer
> > though which does make me nervous about whether we have tested
> > this
> > series enough.
> > 
> > Jonathan
> >   
> > > ---
> > >  drivers/iio/iio_core.h            |   4 +
> > >  drivers/iio/industrialio-buffer.c | 120  
> > +++++++++++++++++++++++++++++-  
> > >  drivers/iio/industrialio-core.c   |   1 +
> > >  include/linux/iio/buffer.h        |   7 ++
> > >  include/linux/iio/buffer_impl.h   |  11 +++
> > >  5 files changed, 141 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
> > > index 8f4a9b264962..61e318431de9 100644
> > > --- a/drivers/iio/iio_core.h
> > > +++ b/drivers/iio/iio_core.h
> > > @@ -68,12 +68,15 @@ __poll_t iio_buffer_poll_wrapper(struct file  
> > *filp,  
> > >  				 struct poll_table_struct *wait);
> > >  ssize_t iio_buffer_read_wrapper(struct file *filp, char __user *buf,
> > >  				size_t n, loff_t *f_ps);
> > > +ssize_t iio_buffer_write_wrapper(struct file *filp, const char __user  
> > *buf,  
> > > +				 size_t n, loff_t *f_ps);
> > >
> > >  int iio_buffers_alloc_sysfs_and_mask(struct iio_dev *indio_dev);
> > >  void iio_buffers_free_sysfs_and_mask(struct iio_dev *indio_dev);
> > >
> > >  #define iio_buffer_poll_addr (&iio_buffer_poll_wrapper)
> > >  #define iio_buffer_read_outer_addr (&iio_buffer_read_wrapper)
> > > +#define iio_buffer_write_outer_addr  
> > (&iio_buffer_write_wrapper)  
> > >
> > >  void iio_disable_all_buffers(struct iio_dev *indio_dev);
> > >  void iio_buffer_wakeup_poll(struct iio_dev *indio_dev);
> > > @@ -83,6 +86,7 @@ void iio_device_detach_buffers(struct iio_dev  
> > *indio_dev);  
> > >
> > >  #define iio_buffer_poll_addr NULL
> > >  #define iio_buffer_read_outer_addr NULL
> > > +#define iio_buffer_write_outer_addr NULL
> > >
> > >  static inline int iio_buffers_alloc_sysfs_and_mask(struct iio_dev  
> > *indio_dev)  
> > >  {
> > > diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-  
> > buffer.c  
> > > index a95cc2da56be..a2a34c5652a7 100644
> > > --- a/drivers/iio/industrialio-buffer.c
> > > +++ b/drivers/iio/industrialio-buffer.c
> > > @@ -161,6 +161,62 @@ static ssize_t iio_buffer_read(struct file *filp,  
> > char __user *buf,  
> > >  	return ret;
> > >  }
> > >
> > > +static size_t iio_buffer_space_available(struct iio_buffer *buf)
> > > +{
> > > +	if (buf->access->space_available)
> > > +		return buf->access->space_available(buf);
> > > +
> > > +	return SIZE_MAX;
> > > +}
> > > +
> > > +static ssize_t iio_buffer_write(struct file *filp, const char __user  
> > *buf,  
> > > +				size_t n, loff_t *f_ps)
> > > +{
> > > +	struct iio_dev_buffer_pair *ib = filp->private_data;
> > > +	struct iio_buffer *rb = ib->buffer;
> > > +	struct iio_dev *indio_dev = ib->indio_dev;
> > > +	DEFINE_WAIT_FUNC(wait, woken_wake_function);
> > > +	int ret;
> > > +	size_t written;
> > > +
> > > +	if (!indio_dev->info)
> > > +		return -ENODEV;
> > > +
> > > +	if (!rb || !rb->access->write)
> > > +		return -EINVAL;
> > > +  
> 
> As the buffer implementation can support both 'read()' and 'write()', the following
> check might make sense:
> 
> if (rb->direction != IIO_BUFFER_DIRECTION_OUT)
>       return -EPERM;

Makes sense.  Whether EPERM is the right error code is a different question.
Doesn't seem perfectly aligned with this case, but it's not too bad.

Jonathan

> 
> If going with this, we should add an extra patch to do a similar thing on the read side...
> 
> - Nuno Sá
>