> > > +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á
> >
>
