[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1a2db366-a611-4454-a86e-cf7df9cbc358@mailbox.org>
Date: Wed, 28 Jan 2026 15:33:03 +0100
From: Marek Vasut <marek.vasut@...lbox.org>
To: Thomas Gleixner <tglx@...nel.org>, linux-input@...r.kernel.org
Cc: "Peter Zijlstra (Intel)" <peterz@...radead.org>,
Cheng-Yang Chou <yphbchou0911@...il.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>, Frank Li <Frank.Li@....com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Jinjie Ruan <ruanjinjie@...wei.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@....qualcomm.com>,
Marc Zyngier <maz@...nel.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH 1/2] linux/interrupt.h: allow "guard" notation to disable
and reenable IRQ with valid IRQ check
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!
Powered by blists - more mailing lists