public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/8] arm64/mte: Move shift from definition of TCF0 enumeration values
Date: Thu, 21 Apr 2022 10:33:51 +0100	[thread overview]
Message-ID: <YmEk/+s1agzgM9gW@FVFF77S0Q05N> (raw)
In-Reply-To: <20220419104329.188489-2-broonie@kernel.org>

Hi Mark,

I've obviously in favour of scripting, and the changes below look sound to me, so:

Acked-by: Mark Rutland <mark.rutland@arm.com>

I have a couple of minor comments on the commit message, and one suggestion on
the actual code, but the ack stands either way.

On Tue, Apr 19, 2022 at 11:43:22AM +0100, Mark Brown wrote:
> In preparation for automatic generation of SCTLR_EL1 register definitions
> move the shifting of the enumeration values for the TCF0 field from the
> defines in the header to the point where they are used.

It might be worth saying explicitly that this is because the scripting
consistently define enum values *without* shifting.

Likewise saying that the MASK definition is deliberately left shifted as that
defines the bit position of the field, and can be used with FIELD_GET() /
FIELD_PREP().

You can also add something like:

  There should be no functional change as a result of this patch

... to make it clear that this is just a refactoring.

> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/include/asm/sysreg.h | 8 ++++----
>  arch/arm64/kernel/mte.c         | 6 +++---
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index fbf5f8bb9055..ff7693902686 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -678,10 +678,10 @@
>  #define SCTLR_EL1_ATA0		(BIT(42))
>  
>  #define SCTLR_EL1_TCF0_SHIFT	38
> -#define SCTLR_EL1_TCF0_NONE	(UL(0x0) << SCTLR_EL1_TCF0_SHIFT)
> -#define SCTLR_EL1_TCF0_SYNC	(UL(0x1) << SCTLR_EL1_TCF0_SHIFT)
> -#define SCTLR_EL1_TCF0_ASYNC	(UL(0x2) << SCTLR_EL1_TCF0_SHIFT)
> -#define SCTLR_EL1_TCF0_ASYMM	(UL(0x3) << SCTLR_EL1_TCF0_SHIFT)
> +#define SCTLR_EL1_TCF0_NONE	UL(0x0)
> +#define SCTLR_EL1_TCF0_SYNC	UL(0x1)
> +#define SCTLR_EL1_TCF0_ASYNC	UL(0x2)
> +#define SCTLR_EL1_TCF0_ASYMM	UL(0x3)
>  #define SCTLR_EL1_TCF0_MASK	(UL(0x3) << SCTLR_EL1_TCF0_SHIFT)
>  
>  #define SCTLR_EL1_BT1		(BIT(36))
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index 78b3e0f8e997..77614f8bc463 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -216,11 +216,11 @@ static void mte_update_sctlr_user(struct task_struct *task)
>  	 * default order.
>  	 */
>  	if (resolved_mte_tcf & MTE_CTRL_TCF_ASYMM)
> -		sctlr |= SCTLR_EL1_TCF0_ASYMM;
> +		sctlr |= SCTLR_EL1_TCF0_ASYMM << SCTLR_EL1_TCF0_SHIFT;

Generally we should probably use FIELD_PREP()/FIELD_GET() in C code, so maybe
we should make this:

		sctlr |= FIELD_PREP(SCTLR_EL1_TCF0_MASK, SCTLR_EL1_TCF0_ASYMM);

Going forward, it might be worth having some helpers that allow us to avoid the
redundant bits, and save humans having to care about how we namespace the
definitions, e.g.

		sctlr |= SYS_FIELD_PREP(SCTLR_EL1, TCF0, 0x0);
	is:
		sctlr |= FIELD_PREP(SCTLR_EL1_TCF0_MASK, 0x0);


		sctlr |= SYS_FIELD_PREP_ENUM(SCTLR_EL1, TCF0, ASYMM);
	is
		sctlr |= FIELD_PREP(SCTLR_EL1_TCF0_MASK, SCTLR_EL1_TCF0_ASYMM);

Thanks,
Mark.

>  	else if (resolved_mte_tcf & MTE_CTRL_TCF_ASYNC)
> -		sctlr |= SCTLR_EL1_TCF0_ASYNC;
> +		sctlr |= SCTLR_EL1_TCF0_ASYNC << SCTLR_EL1_TCF0_SHIFT;
>  	else if (resolved_mte_tcf & MTE_CTRL_TCF_SYNC)
> -		sctlr |= SCTLR_EL1_TCF0_SYNC;
> +		sctlr |= SCTLR_EL1_TCF0_SYNC << SCTLR_EL1_TCF0_SHIFT;
>  	task->thread.sctlr_user = sctlr;
>  }
>  
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-04-21  9:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
2022-04-19 10:43 ` [PATCH v4 1/8] arm64/mte: Move shift from definition of TCF0 enumeration values Mark Brown
2022-04-21  9:33   ` Mark Rutland [this message]
2022-04-19 10:43 ` [PATCH v4 2/8] arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names Mark Brown
2022-04-21  9:35   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 3/8] arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI Mark Brown
2022-04-21  9:36   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 4/8] arm64: Add sysreg header generation scripting Mark Brown
2022-04-21  9:47   ` Mark Rutland
2022-04-21 13:00     ` Mark Brown
2022-04-21 14:16       ` Mark Rutland
2022-04-21 14:50         ` Mark Brown
2022-04-21 15:35           ` Mark Rutland
2022-04-21 15:46             ` Mark Brown
2022-04-19 10:43 ` [PATCH v4 5/8] arm64/sysreg: Enable automatic generation of system register definitions Mark Brown
2022-04-21  9:52   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 6/8] arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1 Mark Brown
2022-04-21  9:58   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 7/8] arm64/sysreg: Generate definitions for TTBRn_EL1 Mark Brown
2022-04-21  9:59   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1 Mark Brown
2022-04-21 10:05   ` Mark Rutland
2022-04-22 12:14     ` Mark Brown
2022-04-22 13:42       ` Mark Rutland
2022-04-22 13:50         ` Mark Brown
2022-04-21 10:15 ` [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Rutland
2022-04-21 15:14   ` Mark Brown

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=YmEk/+s1agzgM9gW@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=suzuki.poulose@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox