linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, akos.denke@arm.com,
	andre.przywara@arm.com, luca.fancellu@arm.com
Subject: Re: [BOOT-WRAPPER 03/11] aarch64: Implement cpu_init_arch()
Date: Fri, 02 Aug 2024 10:29:36 +0100	[thread overview]
Message-ID: <86h6c31ddr.wl-maz@kernel.org> (raw)
In-Reply-To: <20240729161501.1806271-4-mark.rutland@arm.com>

On Mon, 29 Jul 2024 17:14:53 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
> 
> When the boot-wrapper is entered at EL2 it does not initialise
> CNTFRQ_EL0, and in future it may need to initialize other CPU state
> regardless of the exeption level it was entered at.
> 
> Use a common cpu_init_arch() function to initialize CPU state regardless
> of the exception level the boot-wrapper was entered at.
> 
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Akos Denke <akos.denke@arm.com>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Luca Fancellu <luca.fancellu@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> ---
>  arch/aarch64/boot.S |  4 +++-
>  arch/aarch64/init.c | 12 +++++++++---
>  2 files changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S
> index 51ef41b..d8d38dd 100644
> --- a/arch/aarch64/boot.S
> +++ b/arch/aarch64/boot.S
> @@ -51,7 +51,7 @@ reset_at_el3:
>  
>  	bl	cpu_init_bootwrapper
>  
> -	bl	cpu_init_el3
> +	bl	cpu_init_arch
>  
>  	bl	gic_secure_init
>  
> @@ -82,6 +82,8 @@ reset_at_el2:
>  
>  	bl	cpu_init_bootwrapper
>  
> +	bl	cpu_init_arch
> +
>  	b	start_bootmethod
>  
>  err_invalid_id:
> diff --git a/arch/aarch64/init.c b/arch/aarch64/init.c
> index c9fc7f1..49abdf7 100644
> --- a/arch/aarch64/init.c
> +++ b/arch/aarch64/init.c
> @@ -52,7 +52,7 @@ static inline bool cpu_has_permission_indirection(void)
>  	return mrs(ID_AA64MMFR3_EL1) & mask;
>  }
>  
> -void cpu_init_el3(void)
> +static void cpu_init_el3(void)
>  {
>  	unsigned long scr = SCR_EL3_RES1 | SCR_EL3_NS | SCR_EL3_HCE;
>  	unsigned long mdcr = 0;
> @@ -153,8 +153,6 @@ void cpu_init_el3(void)
>  
>  		msr(SMCR_EL3, smcr);
>  	}
> -
> -	msr(CNTFRQ_EL0, COUNTER_FREQ);
>  }
>  
>  #ifdef PSCI
> @@ -171,3 +169,11 @@ bool cpu_init_psci_arch(void)
>  	return true;
>  }
>  #endif
> +
> +void cpu_init_arch(void)
> +{
> +	if (mrs(CurrentEL) == CURRENTEL_EL3)
> +		cpu_init_el3();
> +
> +	msr(CNTFRQ_EL0, COUNTER_FREQ);
> +}

Hmmm. This means that you cannot use the BW on a system where EL3 is
implemented, but where you decide to enter at EL2 anyway (the write to
CNTFRQ_EL0 will UNDEF).

I don't care much (I always want the BW to be the first piece of SW to
run), but this is a rather subtle change in behaviour, and we'd better
capture it in the commit message.

With that,

Acked-by: Marc Zyngier <maz@kernel.org>

	M.

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


  reply	other threads:[~2024-08-02  9:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-29 16:14 [BOOT-WRAPPER 00/11] Cleanup initialization Mark Rutland
2024-07-29 16:14 ` [BOOT-WRAPPER 01/11] Always enter AArch32 kernels in ARM mode Mark Rutland
2024-08-02 11:26   ` Andre Przywara
2024-08-03 10:53     ` Mark Rutland
2024-07-29 16:14 ` [BOOT-WRAPPER 02/11] aarch64: Remove redundant EL1 entry logic Mark Rutland
2024-07-29 16:14 ` [BOOT-WRAPPER 03/11] aarch64: Implement cpu_init_arch() Mark Rutland
2024-08-02  9:29   ` Marc Zyngier [this message]
2024-08-02  9:38     ` Mark Rutland
2024-07-29 16:14 ` [BOOT-WRAPPER 04/11] aarch64: Always enter kernel via exception return Mark Rutland
2024-07-29 16:14 ` [BOOT-WRAPPER 05/11] aarch32: Refactor inital entry Mark Rutland
2024-07-29 16:14 ` [BOOT-WRAPPER 06/11] aarch32: Implement cpu_init_arch() Mark Rutland
2024-07-29 16:14 ` [BOOT-WRAPPER 07/11] aarch32: Always enter kernel via exception return Mark Rutland
2024-07-29 16:14 ` [BOOT-WRAPPER 08/11] Unify assembly setup paths Mark Rutland
2024-07-29 16:14 ` [BOOT-WRAPPER 09/11] Simplify spin logic Mark Rutland
2024-07-29 16:15 ` [BOOT-WRAPPER 10/11] Add printing functions Mark Rutland
2024-07-29 16:15 ` [BOOT-WRAPPER 11/11] Boot CPUs sequentially Mark Rutland
2024-07-31  9:57   ` Luca Fancellu
2024-08-03 10:57     ` Mark Rutland
2024-08-02 10:18 ` [BOOT-WRAPPER 00/11] Cleanup initialization Marc Zyngier

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=86h6c31ddr.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=akos.denke@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=luca.fancellu@arm.com \
    --cc=mark.rutland@arm.com \
    /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;
as well as URLs for NNTP newsgroup(s).