Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230420102316.757-1-honda@mechatrax.com> <20230423121528.259d3cd4@jic23-huawei>
 <b6a96cca17832219042c90baec2442b1a5bad7b7.camel@gmail.com> <20230430184311.7443e1d7@jic23-huawei>
In-Reply-To: <20230430184311.7443e1d7@jic23-huawei>
From:   Masahiro Honda <honda@mechatrax.com>
Date:   Mon, 1 May 2023 19:45:46 +0900
Message-ID: <CA+Tz-SHPt_Kcwvmt6Xq0-DgkQC835UWeajjq28-qku+urxRQvA@mail.gmail.com>
Subject: Re: [PATCH v3] Fix IRQ issue by setting IRQ_DISABLE_UNLAZY flag
To:     Jonathan Cameron <jic23@kernel.org>
Cc:     =?UTF-8?B?TnVubyBTw6E=?= <noname.nuno@gmail.com>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Michael Hennerich <Michael.Hennerich@analog.com>,
        linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi all,

On Mon, May 1, 2023 at 2:27=E2=80=AFAM Jonathan Cameron <jic23@kernel.org> =
wrote:
>
> On Mon, 24 Apr 2023 11:09:34 +0200
> Nuno S=C3=A1 <noname.nuno@gmail.com> wrote:
>
> > Hi Jonathan,
> >
> > On Sun, 2023-04-23 at 12:15 +0100, Jonathan Cameron wrote:
> > > On Thu, 20 Apr 2023 19:23:16 +0900
> > > Masahiro Honda <honda@mechatrax.com> wrote:
> > >
> > > > The Sigma-Delta ADCs supported by this driver can use SDO as an int=
errupt
> > > > line to indicate the completion of a conversion. However, some devi=
ces
> > > > cannot properly detect the completion of a conversion by an interru=
pt.
> > > > This is for the reason mentioned in the following commit.
> > > >
> > > > commit e9849777d0e2 ("genirq: Add flag to force mask in
> > > >                       disable_irq[_nosync]()")
> > > >
> > > > A read operation is performed by an extra interrupt before the comp=
letion
> > > > of a conversion. This patch fixes the issue by setting IRQ_DISABLE_=
UNLAZY
> > > > flag.
> > > >
> > > > Signed-off-by: Masahiro Honda <honda@mechatrax.com>
> > > > ---
> > > > v3:
> > > >  - Remove the Kconfig option.
> > > > v2:
> > > > https://lore.kernel.org/linux-iio/20230414102744.150-1-honda@mechat=
rax.com/
> > > >  - Rework commit message.
> > > >  - Add a new entry in the Kconfig.
> > > >  - Call irq_clear_status_flags(irq, IRQ_DISABLE_UNLAZY) when freein=
g the
> > > > IRQ.
> > > > v1:
> > > > https://lore.kernel.org/linux-iio/20230306044737.862-1-honda@mechat=
rax.com/
> > > >
> > > >  drivers/iio/adc/ad_sigma_delta.c | 25 ++++++++++++++++++++-----
> > > >  1 file changed, 20 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/iio/adc/ad_sigma_delta.c
> > > > b/drivers/iio/adc/ad_sigma_delta.c
> > > > index d8570f620..215ecbedb 100644
> > > > --- a/drivers/iio/adc/ad_sigma_delta.c
> > > > +++ b/drivers/iio/adc/ad_sigma_delta.c
> > > > @@ -565,6 +565,14 @@ int ad_sd_validate_trigger(struct iio_dev *ind=
io_dev,
> > > > struct iio_trigger *trig)
> > > >  }
> > > >  EXPORT_SYMBOL_NS_GPL(ad_sd_validate_trigger, IIO_AD_SIGMA_DELTA);
> > > >
> > > > +static void ad_sd_free_irq(void *sd)
> > > > +{
> > > > +       struct ad_sigma_delta *sigma_delta =3D sd;
> > > > +
> > > > +       irq_clear_status_flags(sigma_delta->spi->irq, IRQ_DISABLE_U=
NLAZY);
> > > > +       free_irq(sigma_delta->spi->irq, sigma_delta);
> > > > +}
> > >
> > > Don't fuse the two operations unwinding like this.  Just register a c=
allback
> > > that only
> > > does the irq_clear_status_flags immediately after setting them.  Then=
 leave
> >
> > I was the one to propose fusing them together because I thought that we=
 could
> > have issues by clearing the flag after calling free_irq(). After lookin=
g again
> > at the IRQ code, I can see that it is not up to free_irq() to free the =
allocated
> > irq_descs (that might only happen when unmapping the virq) which means =
we should
> > be fine doing the normal way.
>
> Ah. I'd missed the ordering.  If that had been valid (and I think you are=
 correct
> that it is not required) then a comment to make that clear would be neces=
sary.
>
> Usual case of: When doing something non obvious with ordering, say why.
>
> >
> > That said, looking at the only users that care to clear this flag, it l=
ooks like
> > they do it before calling free_irq(). Hence, I'm not sure if there's an=
ything
> > subtle going on. In fact, looking at this line:
> >
> > https://elixir.bootlin.com/linux/latest/source/kernel/irq/manage.c#L190=
9
> >
> > I'm not so sure we actually need to clear the flag as for these devices=
, we
> > should only have one consumer/action per IRQ. Anyways, probably for cor=
rectness
> > we should still explicitly clear it?
>
> Good question...  Looks to me like a driver shouldn't be clearing this fl=
ag
> itself, but it's probably harmless in most cases.
>
> I'd drop the clear of the status flag, perhaps adding a comment that
> the irq core does it for us.
>
> Jonathan
>
>
> >
> > - Nuno S=C3=A1
> >
>

I'll remove the callback and just call irq_set_status_flags() with a commen=
t.

Thanks,

Masahiro