All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: mark.rutland@arm.com, smostafa@google.com, kees@kernel.org,
	catalin.marinas@arm.com, Jinjie Ruan <ruanjinjie@huawei.com>,
	linux-kernel@vger.kernel.org, mrigendra.chaubey@gmail.com,
	leitao@debian.org, will@kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: traps: Add a macro to simplify the condition codes check
Date: Thu, 23 Apr 2026 09:04:39 +0100	[thread overview]
Message-ID: <868qae14rs.wl-maz@kernel.org> (raw)
In-Reply-To: <ae6f2b57-4644-424e-aab7-84042dca23e6@arm.com>

On Thu, 23 Apr 2026 06:29:09 +0100,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> 
> 
> 
> On 20/03/26 1:58 PM, Jinjie Ruan wrote:
> > Add DEFINE_COND_CHECK macro to define the simple __check_* functions
> > to simplify the condition codes check.
> > 
> > No functional changes.
> > 
> > Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> > ---
> >  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 <asm/system_misc.h>
> >  #include <asm/sysreg.h>
> >  
> > -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 */
> 
> 	(((pstate & 0 == 0) != 0) == false) ---> return true 
> 
> Although this looks OK but wondering if __check_al() should
> be left unchanged for simplicity. OR could all its call sites
> be changed assuming an unconditional 'true' return thus later
> __check_al() can be dropped.

Which call site? We emulate an instruction, and we're not in control
of the condition code associated with it. The condition code directly
indexes into aarch32_opcode_cond_checks[].

Anyway, this is a moot point, as we have consensus to not touch that
code at all.

	M.

-- 
Without deviation from the norm, progress is not possible.


      reply	other threads:[~2026-04-23  8:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-20  8:28 [PATCH] arm64: traps: Add a macro to simplify the condition codes check Jinjie Ruan
2026-04-22  3:06 ` Jinjie Ruan
2026-04-22 14:43   ` Vladimir Murzin
2026-04-22 15:16     ` Mark Rutland
2026-04-23  5:29 ` Anshuman Khandual
2026-04-23  8:04   ` Marc Zyngier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=868qae14rs.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=kees@kernel.org \
    --cc=leitao@debian.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mrigendra.chaubey@gmail.com \
    --cc=ruanjinjie@huawei.com \
    --cc=smostafa@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.