Received-SPF: pass (google.com: domain of linux-kernel+bounces-11547-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Tue, 26 Dec 2023 15:30:37 +0000
From: Jonathan Cameron <jic23@kernel.org>
To: Nuno =?UTF-8?B?U8Oh?= <noname.nuno@gmail.com>
Cc: Paul Cercueil <paul@crapouillou.net>, Lars-Peter Clausen
 <lars@metafoo.de>, Sumit Semwal <sumit.semwal@linaro.org>, Christian
 =?UTF-8?B?S8O2bmln?= <christian.koenig@amd.com>, Vinod Koul
 <vkoul@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
 linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
 dmaengine@vger.kernel.org, linux-iio@vger.kernel.org,
 linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
 linaro-mm-sig@lists.linaro.org, Michael Hennerich
 <Michael.Hennerich@analog.com>
Subject: Re: [PATCH v5 6/8] iio: buffer-dma: Enable support for DMABUFs
Message-ID: <20231226153037.1a2052f3@jic23-huawei>
In-Reply-To: <219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.camel@gmail.com>
References: <20231219175009.65482-1-paul@crapouillou.net>
	<20231219175009.65482-7-paul@crapouillou.net>
	<20231221160445.0e3e5a8c@jic23-huawei>
	<219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.camel@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


> > > +struct iio_dma_buffer_block *
> > > +iio_dma_buffer_attach_dmabuf(struct iio_buffer *buffer,
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 struct dma_buf_attachment *attach)
> > > +{
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0struct iio_dma_buffer_queu=
e *queue =3D iio_buffer_to_queue(buffer);
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0struct iio_dma_buffer_bloc=
k *block;
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int err;
> > > +
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0mutex_lock(&queue->lock); =
=20
> >=20
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0guard(mutex)(&queue->lo=
ck); =20
>=20
> I'm also a big fan of this new stuff but shouldn't we have a prep patch m=
aking the
> transition to that? Otherwise we'll end up with a mix of styles. I'm happ=
y 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.=20

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 peop=
le want to use
scoped_guard() or guard for these just to be consistent.  Either way is pre=
tty
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


>=20
> - Nuno S=C3=A1
> >  =20
>=20