Received-SPF: pass (google.com: domain of linux-kernel+bounces-135035-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <b6c6700d924916dd09afd2878321a7c87b8e922d.camel@gmail.com>
Subject: Re: [PATCH v1] iio: adc: ad_sigma_delta: Clear pending interrupts
 before enable
From: Nuno =?ISO-8859-1?Q?S=E1?= <noname.nuno@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>, Markus Burri <markus.burri@mt.com>
Cc: linux-kernel@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>, 
 Michael Hennerich <Michael.Hennerich@analog.com>,
 linux-iio@vger.kernel.org, Nuno Sa <nuno.sa@analog.com>
Date: Mon, 08 Apr 2024 10:31:21 +0200
In-Reply-To: <20240406171728.16170b48@jic23-huawei>
References: <20240404175126.110208-1-markus.burri@mt.com>
	 <20240406171728.16170b48@jic23-huawei>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.0 
Precedence: bulk
MIME-Version: 1.0

On Sat, 2024-04-06 at 17:17 +0100, Jonathan Cameron wrote:
> On Thu,=C2=A0 4 Apr 2024 19:51:26 +0200
> Markus Burri <markus.burri@mt.com> wrote:
>=20
> Hi Markus,
>=20
>=20
> > For device will enable and disable irq contiously like AD7195,
> > it use DOUT/RDY pin for both SPI transfer and data ready.
> > It will disable irq during SPI transfer, and re-eanble irq after SPI
> > transfer.
> > That may cause irq status bit set to 1 during spi transfer.
>=20
> Superficially that sounds like it might be an irq driver bug to me...
> Or just possibly an irq chip doing lazy disabling?

Yes, this sounds odd as we are already explicitly disabling lazy disabling:

https://elixir.bootlin.com/linux/latest/source/drivers/iio/adc/ad_sigma_del=
ta.c#L589

>=20
> >=20
> > When the active condition has been detected, the corresponding bit
> > remains set until cleared by software. Status flags are cleared
> > by writing a 1 to the corresponding bit position.
> >=20
> > Signed-off-by: Markus Burri <markus.burri@mt.com>
>=20
> I'll need an appropriate ADI ack for this one.
>=20

Yeah, I wanted to reply to this one Friday but then completely forgot. I ca=
n't
really ack this one. I would need some insights from someone with more core=
 IRQ
knowledge. But...

> It seems highly unusual to be calling a generic irqchip related function =
in a
> driver (there are no other such users).=C2=A0 So this seems unlikely to b=
e
> the right fix for this particular problem.
>=20

Yes, and this (I think) would not even fix (if a fix is needed) this for al=
l
irqchips which to me already sounds not the way to go.

- Nuno S=C3=A1
>=20