From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C8AA334AAF2 for ; Wed, 22 Apr 2026 15:17:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776871022; cv=none; b=JP6xlcg68RxlmCN1nX3mdjIfu5jGtO9FexOVzZZQP6sXuNtJSgZyR4YYxfIIT3lKpg/D5PvEe0Dz9dx92Gx0PmAqvOgHaKmN1K4ztJyY93TeytSiC6OxIS4yRSswhpSifUJ6bx8QgsQsgsDtuNXRidlOhfL1XXiH/U9pSOqqhpc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776871022; c=relaxed/simple; bh=is7cxhJlVLded2ZLMSS+IvUViROU730IKILupbj7wo8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KRmg39LMY/zePyXjF8m7GleCDqL2KyMS92dCPRsq7Olzb0VajxQisBUyK2z6hTULWF2hjQywMN+i2/BLUJ44ds5jh6ZnKkgVXj1QzVXzmNMO8Cph+TLlmxdYcH+J9vv9/OW23s7A85eZ81tyvU/mrJ27Gd1KOwwMulJUyaf77Ys= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=f26MVB5b; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="f26MVB5b" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 49ADE1F91; Wed, 22 Apr 2026 08:16:54 -0700 (PDT) Received: from J2N7QTR9R3.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E6B8B3FD88; Wed, 22 Apr 2026 08:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1776871019; bh=is7cxhJlVLded2ZLMSS+IvUViROU730IKILupbj7wo8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=f26MVB5bIq1vmZaS9GBkOn6c0U1QrIqSx4lli8yfL3RzLdfcMWWEJLoyU3B5p2de5 9FTvwyJfEqWfxFkff5Xu4mM8+qLuOi6NVYfHQCN5lnxgyNPA0geWvn+6hCW/wISIgW qH3p+2CvsE6tu4Qr7aRoFRFy1pJs4Eoyj6q5EhMI= Date: Wed, 22 Apr 2026 16:16:53 +0100 From: Mark Rutland To: Vladimir Murzin Cc: Jinjie Ruan , catalin.marinas@arm.com, will@kernel.org, kees@kernel.org, maz@kernel.org, ada.coupriediaz@arm.com, smostafa@google.com, leitao@debian.org, mrigendra.chaubey@gmail.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: traps: Add a macro to simplify the condition codes check Message-ID: References: <20260320082846.1235016-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Apr 22, 2026 at 03:43:39PM +0100, Vladimir Murzin wrote: > Hi Jinjie, > > On 4/22/26 04:06, Jinjie Ruan wrote: > > > > On 3/20/2026 4:28 PM, Jinjie Ruan wrote: > >> Add DEFINE_COND_CHECK macro to define the simple __check_* functions > >> to simplify the condition codes check. > >> > >> No functional changes. > > Gentle ping. > > > >> Signed-off-by: Jinjie Ruan > >> --- > >> arch/arm64/kernel/traps.c | 59 ++++++++++----------------------------- > >> 1 file changed, 15 insertions(+), 44 deletions(-) > >> > >> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > >> index 914282016069..6216fe9e8e42 100644 > >> --- a/arch/arm64/kernel/traps.c > >> +++ b/arch/arm64/kernel/traps.c > >> @@ -49,45 +49,21 @@ > >> #include > >> #include > >> > >> -static bool __kprobes __check_eq(unsigned long pstate) > >> -{ > >> - return (pstate & PSR_Z_BIT) != 0; > >> -} > >> - > >> -static bool __kprobes __check_ne(unsigned long pstate) > >> -{ > >> - return (pstate & PSR_Z_BIT) == 0; > >> -} > >> - > >> -static bool __kprobes __check_cs(unsigned long pstate) > >> -{ > >> - return (pstate & PSR_C_BIT) != 0; > >> -} > >> - > >> -static bool __kprobes __check_cc(unsigned long pstate) > >> -{ > >> - return (pstate & PSR_C_BIT) == 0; > >> -} > >> - > >> -static bool __kprobes __check_mi(unsigned long pstate) > >> -{ > >> - return (pstate & PSR_N_BIT) != 0; > >> -} > >> - > >> -static bool __kprobes __check_pl(unsigned long pstate) > >> -{ > >> - return (pstate & PSR_N_BIT) == 0; > >> -} > >> - > >> -static bool __kprobes __check_vs(unsigned long pstate) > >> -{ > >> - return (pstate & PSR_V_BIT) != 0; > >> -} > >> - > >> -static bool __kprobes __check_vc(unsigned long pstate) > >> -{ > >> - return (pstate & PSR_V_BIT) == 0; > >> -} > >> +#define DEFINE_COND_CHECK(name, flag, expected) \ > >> +static bool __kprobes __check_##name(unsigned long pstate) \ > >> +{ \ > >> + return ((pstate & (flag)) != 0) == (expected); \ > >> +} > >> + > >> +DEFINE_COND_CHECK(eq, PSR_Z_BIT, true) > >> +DEFINE_COND_CHECK(ne, PSR_Z_BIT, false) > >> +DEFINE_COND_CHECK(cs, PSR_C_BIT, true) > >> +DEFINE_COND_CHECK(cc, PSR_C_BIT, false) > >> +DEFINE_COND_CHECK(mi, PSR_N_BIT, true) > >> +DEFINE_COND_CHECK(pl, PSR_N_BIT, false) > >> +DEFINE_COND_CHECK(vs, PSR_V_BIT, true) > >> +DEFINE_COND_CHECK(vc, PSR_V_BIT, false) > >> +DEFINE_COND_CHECK(al, 0, false) /* Always true */ > >> > >> static bool __kprobes __check_hi(unsigned long pstate) > >> { > >> @@ -131,11 +107,6 @@ static bool __kprobes __check_le(unsigned long pstate) > >> return (temp & PSR_N_BIT) != 0; > >> } > >> > >> -static bool __kprobes __check_al(unsigned long pstate) > >> -{ > >> - return true; > >> -} > >> - > >> /* > >> * Note that the ARMv8 ARM calls condition code 0b1111 "nv", but states that > >> * it behaves identically to 0b1110 ("al"). > > > > It looks like we now have a mix of checks implemented via macros > and others written out explicitly. The existing approach has the > advantage of being consistent and easy to follow, whereas > introducing macros here, even if it reduces some duplication, > adds a bit of cognitive overhead when reading the code. > > This may come down to preference, but I think sticking to a > single, consistent style would make the code easier to scan and > maintain. FWIW, I agree. I think it'd be better to leave this as-is for now. Mark.