Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 18 Feb 2021 19:16:08 +0900
From:   William Breathitt Gray <vilhelm.gray@gmail.com>
To:     Jonathan Cameron <jic23@kernel.org>
Cc:     kernel@pengutronix.de, linux-stm32@st-md-mailman.stormreply.com,
        a.fatoum@pengutronix.de, kamel.bouhara@bootlin.com,
        gwendal@chromium.org, alexandre.belloni@bootlin.com,
        david@lechnology.com, linux-iio@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        syednwaris@gmail.com, patrick.havelange@essensium.com,
        fabrice.gasnier@st.com, mcoquelin.stm32@gmail.com,
        alexandre.torgue@st.com, o.rempel@pengutronix.de
Subject: Re: [PATCH v8 21/22] counter: 104-quad-8: Replace mutex with spinlock
Message-ID: <YC4+aMA6fom7pd4F@shinobu>
References: <cover.1613131238.git.vilhelm.gray@gmail.com>
 <d2e72eac404ca5b7c99d8a642f2c07ebb2eb240a.1613131238.git.vilhelm.gray@gmail.com>
 <20210214181946.1d2f7e78@archlinux>
 <YCsq42hXqdRWrSEd@shinobu>
 <20210216192720.75082d22@archlinux>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="+eKruDaQgZ0deyTo"
Content-Disposition: inline
In-Reply-To: <20210216192720.75082d22@archlinux>
Precedence: bulk


--+eKruDaQgZ0deyTo
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 16, 2021 at 07:27:20PM +0000, Jonathan Cameron wrote:
> On Tue, 16 Feb 2021 11:16:03 +0900
> William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
>=20
> > On Sun, Feb 14, 2021 at 06:19:46PM +0000, Jonathan Cameron wrote:
> > > On Fri, 12 Feb 2021 21:13:45 +0900
> > > William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> > >  =20
> > > > This patch replaces the mutex I/O lock with a spinlock. This is in
> > > > preparation for a subsequent patch adding IRQ support for 104-QUAD-8
> > > > devices; we can't sleep in an interrupt context, so we'll need to u=
se a
> > > > spinlock instead.
> > > >=20
> > > > Cc: Syed Nayyar Waris <syednwaris@gmail.com>
> > > > Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> =20
> > >=20
> > > Why do these need to be raw_spin_locks?
> > > Normally only need to do that if in code related to interrupt chips e=
tc,
> > > not their use.
> > >=20
> > > Jonathan =20
> >=20
> > This lock can be taken in an interrupt context in a subsequent patch:
> > counter_push_event() called by quad8_irq_handler() can end up calling
> > the Counter component callbacks which take this lock. We can't use a
> > mutex nor a regular spinlock because those can sleep on RT setups [1]
>=20
> But on RT setups the interrupts become threads and are preemptable etc,
> so that shouldn't matter.  There are a few corner cases that cause
> trouble, but in most normal drivers you should be fine with a
> spin_lock.
>=20
> Jonathan

Thinking this over again I realize you're probably right. A simple
spin_lock should be fine for these drivers, so I'll switch over to that
instead of the raw_spin_lock for this driver and the Counter interface
code.

William Breathitt Gray

> > which would result in a deadlock due to the interrupt context here -- so
> > therefore we're left with using raw_spin_lock.
> >=20
> > [1] https://lwn.net/Articles/367219/
> >=20
> > William Breathitt Gray
>=20

--+eKruDaQgZ0deyTo
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEk5I4PDJ2w1cDf/bghvpINdm7VJIFAmAuPmcACgkQhvpINdm7
VJJlQQ//TGIj8Nm+JA1eSMPG5CK4MXy5g1jHCLnb9hf2L7kuuE6Szwnsth3IQ6Ds
QHYkyzTiZt1SIAZ/x1cJPyg7sI09H5KUo9mkh+pPqqDodvOynZVDrvCqp/nhIkKx
ued5CyWx9illXCF/Myj9ARoknDxK/k0MEEFHBhdbRaTavauIWrEN4W+tKpw0JMom
OXlssOmPeJ51evjd9YwwUUZgoVhrYneaOqx8NCC6Hv4CXIT9wQLnQsXrg6T8zKb7
FbrITR46MkXZyh5iibbDe7am8rIMYindyEjRQiMitYsOgNFYwdsnHfeNGDvKLmYB
l5bPIfyIzjnfANGKvPfXTaS3umavlkdjbOmpD0dgXoW1XqU8Jk2tsul3Ou3ooqSG
DkxRfRxVk5aRgjoONGJgZPP4kOLGZ4/BV/GABasSXmyXpZ26h/+J39kDg9AHKVH+
CHEf+RVbx3QbXO7UgBC0jK1BdpclRpwJWWgJOUWdn1SNYiTN7mEZUAQMj3AU8PGQ
q3UyIkM/Zd5te/XsfuxVa2GucgRizIRs4WYw/Njmz32gJyVMTiCrskEkFywlA4ZY
HntEfYNJop/zzyCblaLp8/0qEfqDfUg/MpUILqZEobE9+oI2gTJ8HVCLvwUVWN8g
/RgD9t6Gl8LvUZCMAOwswLcZGreYIjO7h0m8jfbUYakB3Y5bYCs=
=enNp
-----END PGP SIGNATURE-----

--+eKruDaQgZ0deyTo--