Re: [PATCH 1/2] linux/interrupt.h: allow "guard" notation to disable and reenable IRQ with valid IRQ check

[Dmitry Torokhov]

On Wed, Jan 28, 2026 at 03:33:03PM +0100, Marek Vasut wrote:
> On 1/28/26 2:49 PM, Thomas Gleixner wrote:
> > On Wed, Jan 28 2026 at 13:23, Marek Vasut wrote:
> > > On 1/27/26 10:14 AM, Thomas Gleixner wrote:
> > > > disable_valid_irq is a pretty non-intuitive name if you look at it just
> > > > by reading a usage site. It's not really improving the readability of
> > > > the code, it's in fact obscuring it as the reader has to actually look
> > > > up what the hell this means and then stumble upon a completely
> > > > undocumented lock guard define.
> > > > 
> > > > I'm all for using guards, but using guards just for the sake of using
> > > > guards is not a really good approach.
> > > I wouldn't even be opposed to converting the ili2xxx driver (the piece
> > > of code in patch 2/2 of this series) back to simple enable/disable_irq()
> > > . I am not particularly on board even with the disable_irq lock guard,
> > > or more specifically, lock guard used for non-lock things like this.
> > 
> > I agree that guard() is a slight misnomer for such usage, but this is
> > about scoped auto cleanups, so using it this way makes a lot of sense
> > when the scope mechanism is sensible.
> It is indeed a misnomer.
> 
> Would you prefer this patch be updated with some better function name, or
> dropped outright until there are surely more users of this functionality ?

Maybe call it "disable_irq_if_valid"?

Thanks.

-- 
Dmitry