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

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

[Marek Vasut]

Introduce disable_valid_irq scoped guard. This is an extension
of disable_irq scoped guard, which disables and enables IRQs
around a scope. The disable_valid_irq scoped guard does almost
the same, except it handles the case where IRQ is not valid,
in which case it does not do anything. This is meant to be used
by for example touch controller drivers, which can do both IRQ
driven and polling mode of operation, and this makes their code
slighly simpler.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Cheng-Yang Chou <yphbchou0911@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
 include/linux/interrupt.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 00c01b0a43be1..becbeab4a7473 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -242,6 +242,21 @@ extern void irq_wake_thread(unsigned int irq, void *dev_id);
 DEFINE_LOCK_GUARD_1(disable_irq, int,
 		    disable_irq(*_T->lock), enable_irq(*_T->lock))
 
+static inline void disable_valid_irq(unsigned int irq)
+{
+	if (irq > 0)
+		disable_irq(irq);
+}
+
+static inline void enable_valid_irq(unsigned int irq)
+{
+	if (irq > 0)
+		enable_irq(irq);
+}
+
+DEFINE_LOCK_GUARD_1(disable_valid_irq, int,
+		    disable_valid_irq(*_T->lock), enable_valid_irq(*_T->lock))
+
 extern void disable_nmi_nosync(unsigned int irq);
 extern void disable_percpu_nmi(unsigned int irq);
 extern void enable_nmi(unsigned int irq);
-- 
2.51.0

[PATCH 2/2] Input: ili210x - convert to disable_valid_irq scoped guard

[Marek Vasut]

Use disable_valid_irq scoped guard to simplify the code and
deduplicate the polling and IRQ driver case. No functional
change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Cheng-Yang Chou <yphbchou0911@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/input/touchscreen/ili210x.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/ili210x.c b/drivers/input/touchscreen/ili210x.c
index 3bf524a6ee204..70abbd675bb01 100644
--- a/drivers/input/touchscreen/ili210x.c
+++ b/drivers/input/touchscreen/ili210x.c
@@ -893,10 +893,7 @@ static ssize_t ili210x_firmware_update_store(struct device *dev,
 	 * the touch controller to disable the IRQs during update, so we have
 	 * to do it this way here.
 	 */
-	if (client->irq > 0) {
-		guard(disable_irq)(&client->irq);
-		error = ili210x_firmware_update(dev, fwbuf, ac_end, df_end);
-	} else {
+	scoped_guard(disable_valid_irq, &client->irq) {
 		error = ili210x_firmware_update(dev, fwbuf, ac_end, df_end);
 	}
 
-- 
2.51.0

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

[Frank Li]

On Thu, Jan 22, 2026 at 12:23:47AM +0100, Marek Vasut wrote:
> Introduce disable_valid_irq scoped guard. This is an extension
> of disable_irq scoped guard, which disables and enables IRQs
> around a scope. The disable_valid_irq scoped guard does almost
> the same, except it handles the case where IRQ is not valid,
> in which case it does not do anything. This is meant to be used
> by for example touch controller drivers, which can do both IRQ
> driven and polling mode of operation, and this makes their code
> slighly simpler.

I think it'd better to give simple example here.

Frank
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
> Cc: Cheng-Yang Chou <yphbchou0911@gmail.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Frank Li <Frank.Li@nxp.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Jinjie Ruan <ruanjinjie@huawei.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: linux-input@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
>  include/linux/interrupt.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 00c01b0a43be1..becbeab4a7473 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -242,6 +242,21 @@ extern void irq_wake_thread(unsigned int irq, void *dev_id);
>  DEFINE_LOCK_GUARD_1(disable_irq, int,
>  		    disable_irq(*_T->lock), enable_irq(*_T->lock))
>
> +static inline void disable_valid_irq(unsigned int irq)
> +{
> +	if (irq > 0)
> +		disable_irq(irq);
> +}
> +
> +static inline void enable_valid_irq(unsigned int irq)
> +{
> +	if (irq > 0)
> +		enable_irq(irq);
> +}
> +
> +DEFINE_LOCK_GUARD_1(disable_valid_irq, int,
> +		    disable_valid_irq(*_T->lock), enable_valid_irq(*_T->lock))
> +
>  extern void disable_nmi_nosync(unsigned int irq);
>  extern void disable_percpu_nmi(unsigned int irq);
>  extern void enable_nmi(unsigned int irq);
> --
> 2.51.0
>

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

[Sebastian Andrzej Siewior]

On 2026-01-22 00:23:47 [+0100], Marek Vasut wrote:
> @@ -242,6 +242,21 @@ extern void irq_wake_thread(unsigned int irq, void *dev_id);
>  DEFINE_LOCK_GUARD_1(disable_irq, int,
>  		    disable_irq(*_T->lock), enable_irq(*_T->lock))
>  
> +static inline void disable_valid_irq(unsigned int irq)
> +{
> +	if (irq > 0)
> +		disable_irq(irq);
> +}

| $ grep " 0:" /proc/interrupts
|    0:         43          0          IO-APIC  2-edge      timer

in other words, interrupt 0 is valid.

Sebastian

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

[Geert Uytterhoeven]

Hi Sebastian,

On Thu, 22 Jan 2026 at 17:22, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> On 2026-01-22 00:23:47 [+0100], Marek Vasut wrote:
> > @@ -242,6 +242,21 @@ extern void irq_wake_thread(unsigned int irq, void *dev_id);
> >  DEFINE_LOCK_GUARD_1(disable_irq, int,
> >                   disable_irq(*_T->lock), enable_irq(*_T->lock))
> >
> > +static inline void disable_valid_irq(unsigned int irq)
> > +{
> > +     if (irq > 0)
> > +             disable_irq(irq);
> > +}
>
> | $ grep " 0:" /proc/interrupts
> |    0:         43          0          IO-APIC  2-edge      timer
>
> in other words, interrupt 0 is valid.

AFAIK, the x86 legacy timer interrupt is the sole remaining valid user
of interrupt number zero.
Nowadays lots of code assumes valid interrupt numbers are non-zero
positive numbers.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Dmitry Torokhov]

On Thu, Jan 22, 2026 at 05:31:42PM +0100, Geert Uytterhoeven wrote:
> Hi Sebastian,
> 
> On Thu, 22 Jan 2026 at 17:22, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
> > On 2026-01-22 00:23:47 [+0100], Marek Vasut wrote:
> > > @@ -242,6 +242,21 @@ extern void irq_wake_thread(unsigned int irq, void *dev_id);
> > >  DEFINE_LOCK_GUARD_1(disable_irq, int,
> > >                   disable_irq(*_T->lock), enable_irq(*_T->lock))
> > >
> > > +static inline void disable_valid_irq(unsigned int irq)
> > > +{
> > > +     if (irq > 0)
> > > +             disable_irq(irq);
> > > +}
> >
> > | $ grep " 0:" /proc/interrupts
> > |    0:         43          0          IO-APIC  2-edge      timer
> >
> > in other words, interrupt 0 is valid.
> 
> AFAIK, the x86 legacy timer interrupt is the sole remaining valid user
> of interrupt number zero.
> Nowadays lots of code assumes valid interrupt numbers are non-zero
> positive numbers.

Quoting an oldie but goodie:

"This has come up before. For example: for an IRQ, 0 means "does not
exist", it does _not_ mean "physical irq 0", and we test for whether a
device has a valid irq by doing "if (dev->irq)" rather than having some
insane architecture-specific "IRQ_NONE". And if you validly really have an
irq at the hardware level that is zero, then that just means that the irq
numbers you should tell the kernel should be translated some way.

(On a PC, hardware irq 0 is a real irq too, but it's a _special_ irq, and
it is set up by architecture-specific code. So as far as the generic
kernel and all devices are concerned, "!dev->irq" means that the irq
doesn't exist or hasn't been mapped for that device yet)."

https://lore.kernel.org/all/Pine.LNX.4.64.0701250940220.25027@woody.linux-foundation.org/

Thanks.

-- 
Dmitry

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

[Sergey Shtylyov]

On 1/22/26 7:31 PM, Geert Uytterhoeven wrote:
[...]

>>> @@ -242,6 +242,21 @@ extern void irq_wake_thread(unsigned int irq, void *dev_id);
>>>  DEFINE_LOCK_GUARD_1(disable_irq, int,
>>>                   disable_irq(*_T->lock), enable_irq(*_T->lock))
>>>
>>> +static inline void disable_valid_irq(unsigned int irq)
>>> +{
>>> +     if (irq > 0)
>>> +             disable_irq(irq);
>>> +}
>>
>> | $ grep " 0:" /proc/interrupts
>> |    0:         43          0          IO-APIC  2-edge      timer
>>
>> in other words, interrupt 0 is valid.
> 
> AFAIK, the x86 legacy timer interrupt is the sole remaining valid user
> of interrupt number zero.
> Nowadays lots of code assumes valid interrupt numbers are non-zero
> positive numbers.

   Makes me remember this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce753ad1549cbe9ccaea4c06a1f5fa47432c8289

> Gr{oetje,eeting}s,
> 
>                         Geert
MBR, Sergey

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

[Marek Vasut]

On 1/22/26 4:38 PM, Frank Li wrote:
> On Thu, Jan 22, 2026 at 12:23:47AM +0100, Marek Vasut wrote:
>> Introduce disable_valid_irq scoped guard. This is an extension
>> of disable_irq scoped guard, which disables and enables IRQs
>> around a scope. The disable_valid_irq scoped guard does almost
>> the same, except it handles the case where IRQ is not valid,
>> in which case it does not do anything. This is meant to be used
>> by for example touch controller drivers, which can do both IRQ
>> driven and polling mode of operation, and this makes their code
>> slighly simpler.
> 
> I think it'd better to give simple example here.
Patch 2/2 is that example , but I can also include it in the commit 
message if this 1/2 is even acceptable.

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

[Thomas Gleixner]

On Thu, Jan 22 2026 at 17:22, Sebastian Andrzej Siewior wrote:

> On 2026-01-22 00:23:47 [+0100], Marek Vasut wrote:
>> @@ -242,6 +242,21 @@ extern void irq_wake_thread(unsigned int irq, void *dev_id);
>>  DEFINE_LOCK_GUARD_1(disable_irq, int,
>>  		    disable_irq(*_T->lock), enable_irq(*_T->lock))
>>  
>> +static inline void disable_valid_irq(unsigned int irq)
>> +{
>> +	if (irq > 0)
>> +		disable_irq(irq);
>> +}
>
> | $ grep " 0:" /proc/interrupts
> |    0:         43          0          IO-APIC  2-edge      timer
>
> in other words, interrupt 0 is valid.

No. It's not really.

Interrupt number zero is a historic leftover and a mistake which is only
relevant to some oddball archaic architectures like x86 and others which
tried to mimic that.

The general agreement is that interrupt 0 is a legacy oddity and only
supported in very special cases. Everything else treats 0 as invalid.

Thanks,

        tglx

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

[Dmitry Torokhov]

Hi Thomas,

On Fri, Jan 23, 2026 at 11:52:58AM +0100, Thomas Gleixner wrote:
> On Thu, Jan 22 2026 at 17:22, Sebastian Andrzej Siewior wrote:
> 
> > On 2026-01-22 00:23:47 [+0100], Marek Vasut wrote:
> >> @@ -242,6 +242,21 @@ extern void irq_wake_thread(unsigned int irq, void *dev_id);
> >>  DEFINE_LOCK_GUARD_1(disable_irq, int,
> >>  		    disable_irq(*_T->lock), enable_irq(*_T->lock))
> >>  
> >> +static inline void disable_valid_irq(unsigned int irq)
> >> +{
> >> +	if (irq > 0)
> >> +		disable_irq(irq);
> >> +}
> >
> > | $ grep " 0:" /proc/interrupts
> > |    0:         43          0          IO-APIC  2-edge      timer
> >
> > in other words, interrupt 0 is valid.
> 
> No. It's not really.
> 
> Interrupt number zero is a historic leftover and a mistake which is only
> relevant to some oddball archaic architectures like x86 and others which
> tried to mimic that.
> 
> The general agreement is that interrupt 0 is a legacy oddity and only
> supported in very special cases. Everything else treats 0 as invalid.

Could you ack this new guard if you agree with it please?

Thanks.

-- 
Dmitry

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

[Thomas Gleixner]

On Thu, Jan 22 2026 at 00:23, Marek Vasut wrote:

$Subject: linux/interrupt.h is not a proper prefix. Just use 'genirq:'

Also what means 'allow ....'? Subject lines should provide a concise
summary of the change, i.e. something like:

        Provide conditional disable_irq guard variant

> Introduce disable_valid_irq scoped guard. This is an extension
> of disable_irq scoped guard, which disables and enables IRQs
> around a scope. The disable_valid_irq scoped guard does almost
> the same, except it handles the case where IRQ is not valid,
> in which case it does not do anything. This is meant to be used
> by for example touch controller drivers, which can do both IRQ
> driven and polling mode of operation, and this makes their code
> slighly simpler.

How many of those have this pattern? From a cursory look I found not
even one as your example is neither applicable to upstream nor to next.

> +static inline void disable_valid_irq(unsigned int irq)
> +{
> +	if (irq > 0)
> +		disable_irq(irq);
> +}
> +
> +static inline void enable_valid_irq(unsigned int irq)
> +{
> +	if (irq > 0)
> +		enable_irq(irq);
> +}
> +
> +DEFINE_LOCK_GUARD_1(disable_valid_irq, int,

'int' because it matches the function argument type of the inlines,
right?

> +		    disable_valid_irq(*_T->lock), enable_valid_irq(*_T->lock))

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.

Thanks,

        tglx

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

[Marek Vasut]

On 1/27/26 10:14 AM, Thomas Gleixner wrote:
> On Thu, Jan 22 2026 at 00:23, Marek Vasut wrote:
> 
> $Subject: linux/interrupt.h is not a proper prefix. Just use 'genirq:'
> 
> Also what means 'allow ....'? Subject lines should provide a concise
> summary of the change, i.e. something like:
> 
>          Provide conditional disable_irq guard variant

I did admittedly replicate the subject and tags from prior commit

c76494768761 ("linux/interrupt.h: allow "guard" notation to disable and 
reenable IRQ")

Fixed, thanks.

>> Introduce disable_valid_irq scoped guard. This is an extension
>> of disable_irq scoped guard, which disables and enables IRQs
>> around a scope. The disable_valid_irq scoped guard does almost
>> the same, except it handles the case where IRQ is not valid,
>> in which case it does not do anything. This is meant to be used
>> by for example touch controller drivers, which can do both IRQ
>> driven and polling mode of operation, and this makes their code
>> slighly simpler.
> 
> How many of those have this pattern? From a cursory look I found not
> even one as your example is neither applicable to upstream nor to next.

One. I think I have two-ish more candidates for conversion.

>> +static inline void disable_valid_irq(unsigned int irq)
>> +{
>> +	if (irq > 0)
>> +		disable_irq(irq);
>> +}
>> +
>> +static inline void enable_valid_irq(unsigned int irq)
>> +{
>> +	if (irq > 0)
>> +		enable_irq(irq);
>> +}
>> +
>> +DEFINE_LOCK_GUARD_1(disable_valid_irq, int,
> 
> 'int' because it matches the function argument type of the inlines,
> right?
> 
>> +		    disable_valid_irq(*_T->lock), enable_valid_irq(*_T->lock))
> 
> 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.

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

[Thomas Gleixner]

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.

Thanks,

        tglx

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

[Marek Vasut]

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 ?

Thank you for your help!

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