From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C867B258CE7; Wed, 28 Jan 2026 14:33:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769610792; cv=none; b=YOlv/4SVaNNNqKw9wYru3RFz1ARJ2SWa+84V8WKxo8OuZ1P71kWp4TBJzyHK/xM6X0fqCBv4nbQLj1bcqG/6s46iPdtl84k3pWroCHqBxi7skyU+WKFLM1Lid4E/8ZsBXRSQ0krFlHphAXWSvcdJCnj4nWR2tTxYggcI9BmkqGc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769610792; c=relaxed/simple; bh=UrecRnUlvslYsUiljuUM/4pYScIjwbM9sj1Vmtaapko=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LZlS9gxoec1KkF823ICYhduGXqVCia18t6DrhEuWPN3/TnEtsMyhIaGJiCkq2J/H1Z1c6q2w92CvuPHZeUucfmS+t6Z5R7soH7xS1G+R3hT5J/NpF/E3ueQy3W7ktjnyMB5Ngc93y5iJMFezoBsUe86b9ke1z3j5lATS+k/Vd6E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=GLlowjzk; arc=none smtp.client-ip=80.241.56.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="GLlowjzk" Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4f1Prg08krz9vBm; Wed, 28 Jan 2026 15:33:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1769610787; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dLVMCXGogj7sIN9RCzxwOPnrNktUHm4xNbMkn6X1plU=; b=GLlowjzkJbOpYnIRBQh+vfw0dMKuCqBaHvb8vOrMtmFsz9N6kLGC524Kcqpop8W3MTGUE5 /RmIFg78Cc+dFKYphidxQSZXwWjzbjygAOUkDs+VWPrUnHJZFGU3RlFmS/fw1akX0r15ba cfHT22VLc2YHiW8krfWjnyy2oCmtSumx+iJYm7YWydZByI7Gp+WeQ4jC9qsb0z4tGlWrd+ qydyKxcwYfuN7CBpHFXwno/7aabXDySHPnOg4FGvVtM72d9LCe5E6jMyiUXfCBID4U5wt9 cRLfJZu8CrOpM6r7eHuVPKDbIX/7KQo4uiG48mbvjciFO0ku6bblC8zZT38HjA== Message-ID: <1a2db366-a611-4454-a86e-cf7df9cbc358@mailbox.org> Date: Wed, 28 Jan 2026 15:33:03 +0100 Precedence: bulk X-Mailing-List: linux-input@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 1/2] linux/interrupt.h: allow "guard" notation to disable and reenable IRQ with valid IRQ check To: Thomas Gleixner , linux-input@vger.kernel.org Cc: "Peter Zijlstra (Intel)" , Cheng-Yang Chou , Dmitry Torokhov , Frank Li , Geert Uytterhoeven , Jinjie Ruan , Krzysztof Kozlowski , Marc Zyngier , Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org References: <20260121232522.154771-1-marek.vasut+renesas@mailbox.org> <87sebrbenj.ffs@tglx> <701e739d-2e82-40e7-87b5-b4ec92903af6@mailbox.org> <871pj9alui.ffs@tglx> Content-Language: en-US From: Marek Vasut In-Reply-To: <871pj9alui.ffs@tglx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-MBO-RS-ID: c9dc477dc1515f58b5c X-MBO-RS-META: hrj98ih6ra6amyj57zpw5xybpfgiw8k8 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!