public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ckadabi@codeaurora.org
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
	mark.rutland@arm.com, will.deacon@arm.com, marc.zyngier@arm.com,
	linux-kernel-owner@vger.kernel.org
Subject: Re: [PATCH 3/3] arm64: Add work around for Arm Cortex-A55 Erratum 1024718
Date: Tue, 16 Jan 2018 19:34:49 -0800	[thread overview]
Message-ID: <5bff2bc7fc3d5d04d8fccc099599dd58@codeaurora.org> (raw)
In-Reply-To: <20180116102323.3470-4-suzuki.poulose@arm.com>

On 2018-01-16 02:23, Suzuki K Poulose wrote:
> Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
> from an erratum 1024718, which causes incorrect updates when DBM/AP
> bits in a page table entry is modified without a break-before-make
> sequence. The work around is to disable the hardware DBM feature
> on the affected cores. The hardware Access Flag management features
> is not affected.
> 
> The hardware DBM feature is a non-conflicting capability, i.e, the
> kernel could handle cores using the feature and those without having
> the features running at the same time. So this work around is detected
> at early boot time, rather than delaying it until the CPUs are brought
> up into the kernel with MMU turned on. This also avoids other 
> complexities
> with late CPUs turning online, with or without the hardware DBM 
> features.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>  Documentation/arm64/silicon-errata.txt |  1 +
>  arch/arm64/Kconfig                     | 14 ++++++++++++++
>  arch/arm64/mm/proc.S                   |  5 +++++
>  3 files changed, 20 insertions(+)
> 
> diff --git a/Documentation/arm64/silicon-errata.txt
> b/Documentation/arm64/silicon-errata.txt
> index b9d93e981a05..5203e71c113d 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -55,6 +55,7 @@ stable kernels.
>  | ARM            | Cortex-A57      | #834220         |
> ARM64_ERRATUM_834220        |
>  | ARM            | Cortex-A72      | #853709         | N/A
>              |
>  | ARM            | Cortex-A73      | #858921         |
> ARM64_ERRATUM_858921        |
> +| ARM            | Cortex-A55      | #1024718        |
> ARM64_ERRATUM_1024718       |
>  | ARM            | MMU-500         | #841119,#826419 | N/A
>              |
>  |                |                 |                 |
>              |
>  | Cavium         | ThunderX ITS    | #22375, #24313  |
> CAVIUM_ERRATUM_22375        |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 664fadc2aa2e..19b8407a0325 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -461,6 +461,20 @@ config ARM64_ERRATUM_843419
> 
>  	  If unsure, say Y.
> 
> +config ARM64_ERRATUM_1024718
> +	bool "Cortex-A55: 1024718: Update of DBM/AP bits without break
> before make might result in incorrect update"
> +	default y
> +	help
> +	  This option adds work around for Arm Cortex-A55 Erratum 1024718.
> +
> +	  Affected Cortex-A55 cores (r0p0, r0p1, r1p0) could cause incorrect
> +	  update of the hardware dirty bit when the DBM/AP bits are updated
> +	  without a break-before-make. The work around is to disable the 
> usage
> +	  of hardware DBM locally on the affected cores. CPUs not affected by
> +	  erratum will continue to use the feature.
> +
> +	  If unsure, say Y.
> +
>  config CAVIUM_ERRATUM_22375
>  	bool "Cavium erratum 22375, 24313"
>  	default y
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 5a59eea49395..ba2c22180f4e 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -252,6 +252,11 @@ ENTRY(__cpu_setup)
>  	cbz	x9, 2f
>  	cmp	x9, #2
>  	b.lt	1f
> +#ifdef CONFIG_ARM64_ERRATUM_1024718
> +	/* Disable hardware DBM on Cortex-A55 r0p0, r0p1 & r1p0 */
> +	cpu_midr_match MIDR_CORTEX_A55, MIDR_CPU_VAR_REV(0, 0),

What is there is a custom core with different MIDRs, can we specify 
multiple MIDR values?
Would it be good to clear the bit as part of 
arch/arm64/kernel/cpu_errata.c so we can specify multiple MIDR values if 
required.

> MIDR_CPU_VAR_REV(1, 0), x1, x2, x3, x4
> +	cbnz	x1, 1f
> +#endif
>  	orr	x10, x10, #TCR_HD		// hardware Dirty flag update
>  1:	orr	x10, x10, #TCR_HA		// hardware Access flag update
>  2:

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2018-01-17  3:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-16 10:23 [PATCH 0/3] arm64: Enable work around for Cortex-A55 erratum 1024718 Suzuki K Poulose
2018-01-16 10:23 ` [PATCH 1/3] arm64: Update MIDR definitions for Arm Cortex-A cores Suzuki K Poulose
2018-01-16 10:23 ` [PATCH 2/3] arm64: Add assembly helpers for MIDR range check Suzuki K Poulose
2018-01-16 10:23 ` [PATCH 3/3] arm64: Add work around for Arm Cortex-A55 Erratum 1024718 Suzuki K Poulose
2018-01-17  3:34   ` ckadabi [this message]
2018-01-17 10:28     ` Suzuki K Poulose
2018-01-18  5:00       ` Channa

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=5bff2bc7fc3d5d04d8fccc099599dd58@codeaurora.org \
    --to=ckadabi@codeaurora.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel-owner@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will.deacon@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