Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: Marco Chen <marcochen.dev@gmail.com>,
	nuno.sa@analog.com, andy@kernel.org, pmeerw@pmeerw.net,
	matt@ranostay.sg, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org, skhan@linuxfoundation.org,
	linux-kernel-mentees@lists.linux.dev
Subject: Re: [PATCH v1] iio: health: max30102: fix NULL dereference in interrupt handler
Date: Sun, 2 Aug 2026 18:41:26 +0100	[thread overview]
Message-ID: <20260802184126.04738251@jic23-huawei> (raw)
In-Reply-To: <89176b25-bcf6-4d44-94b3-7a29abec7b10@baylibre.com>

On Sun, 2 Aug 2026 10:21:41 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On 8/1/26 9:10 PM, Jonathan Cameron wrote:
> > On Sat, 1 Aug 2026 10:18:42 -0500
> > David Lechner <dlechner@baylibre.com> wrote:
> >   
> >> On 7/31/26 1:41 PM, Marco Chen wrote:  
> >>> The interrupt is requested in max30102_probe() and stays enabled    
> >>
> >> I've always wondered why most IIO drivers seem to do this. It seems to
> >> me that requesting the irq with IRQF_NO_AUTOEN and only enabling it
> >> when everything is set up for reading data would avoid spurious interrupts
> >> like this.  
> > 
> > It teaches discipline.  More serious from what I recall the no autoen thing
> > used to be done via a racey bit of trying to turn it off as fast as you can.
> > 
> > Most of the time we should be able to write drivers that don't need to
> > use that flag and don't touch enable_irq() at all.
> > 
> > Obviously that's not always true.
> >   
> 
> Hmm... so I should go back and change [1] since it isn't strictly
> required there?
> 
> [1]: https://lore.kernel.org/linux-iio/20260731-iio-adc-ti-ads112c14-continuous-mode-v2-1-eb13da38e8fc@baylibre.com/
> 
> 

Ah. I was assuming that was spurious irq territory or a device
where we couldn't disable it device end.

I remember a discussion a long time back with the irq maintainers
(probably tglx) about the fact that they really advise drivers not
to turn interrupts on or off because it can be a very expensive
operation on some systems and such control belongs at the device
end when possible. What a host does with a disabled irq is just
too variable. The only guarantee is it won't immediately report it.

Maybe that has changed over time - I have no idea!

Anyhow, yes - I would drop that enable / disable dance if it
was about spurious prevention.  If we want to prevent spurious then
better thing to do is to check the software interrupt status register.
Looks like for that part there is a drdy status bit.   Bit annoying that you'd
have to drop to a thread to read it but we probably should do that
before the complete.  Maybe we could speculatively complete and
check it in the main thread.  

I note you do use that for polling.  I'd treat the irq as a way
to ensure you only need to read it once rather than not read it at all.

Jonathan

  reply	other threads:[~2026-08-02 17:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31 18:41 [PATCH v1] iio: health: max30102: fix NULL dereference in interrupt handler Marco Chen
2026-08-01 15:18 ` David Lechner
2026-08-02  2:10   ` Jonathan Cameron
2026-08-02 15:21     ` David Lechner
2026-08-02 17:41       ` Jonathan Cameron [this message]
2026-08-02  2:26 ` Jonathan Cameron
2026-08-03  4:13   ` Marco Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260802184126.04738251@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel-mentees@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcochen.dev@gmail.com \
    --cc=matt@ranostay.sg \
    --cc=nuno.sa@analog.com \
    --cc=pmeerw@pmeerw.net \
    --cc=skhan@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox