Re: [PATCH v5 6/8] iio: buffer-dma: Enable support for DMABUFs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > +struct iio_dma_buffer_block *
> > > +iio_dma_buffer_attach_dmabuf(struct iio_buffer *buffer,
> > > +                            struct dma_buf_attachment *attach)
> > > +{
> > > +       struct iio_dma_buffer_queue *queue = iio_buffer_to_queue(buffer);
> > > +       struct iio_dma_buffer_block *block;
> > > +       int err;
> > > +
> > > +       mutex_lock(&queue->lock);  
> > 
> >         guard(mutex)(&queue->lock);  
> 
> I'm also a big fan of this new stuff but shouldn't we have a prep patch making the
> transition to that? Otherwise we'll end up with a mix of styles. I'm happy to clean
> up stuff with follow up patches (even some coding style could be improved IIRC) but
> typically that's not how we handle things like this I believe...

Ideally yes, I think a prep patch would make sense - but I'm not that fussed
about it and follow up patches would be fine here. 

There are cases for using this that are much easier to justify than
others, so I don't really mind if simple

mutex_lock();
do_something
mutex_unlock();

cases are left for ever not using guard(), though I also don't mind if people want to use
scoped_guard() or guard for these just to be consistent.  Either way is pretty
easy to read.  We'll probably also continue to gain new uses of this logic such
as the conditional guard stuff that is queued up for the next merge window and
whilst that is going on we are going to have a bit of mixed style.

Jonathan


> 
> - Nuno Sá
> >   
> 






[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux