linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	linux-arm-msm@vger.kernel.org, Andy Gross <agross@kernel.org>,
	Wei Xu <xuwei5@hisilicon.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Robert Richter <rrichter@marvell.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] [RFC] arm64: Add dependencies to vendor-specific errata
Date: Thu, 16 Apr 2020 13:56:31 +0100	[thread overview]
Message-ID: <20200416125630.GF4987@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <20200416115658.20406-3-geert+renesas@glider.be>

Hi Geert,

On Thu, Apr 16, 2020 at 01:56:58PM +0200, Geert Uytterhoeven wrote:
> Currently the user is asked about enabling support for each and every
> vendor-specific erratum, even when support for the specific platform is
> not enabled.
> 
> Fix this by adding platform dependencies to the config options
> controlling support for vendor-specific errata.
> 
> Note that FUJITSU_ERRATUM_010001 is left untouched, as no config symbol
> exists for the Fujitsu A64FX platform.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

I'm not su1re that it makes sense to do this in general, becaose the
ARCH_* platform symbols are about plactform/SoC support (e.g. pinctrl
drivers), and these are (mostly) CPU-local and/or VM-visible.

I think that it makes sense for those to be independent because:

* future SoCs in the same family might not need the same CPU errata
  workarounds, and it's arguably just as confusing to have the option
  there.

* It prevents building a minimal VM image with all (non-virtualized)
  platform support disabled, but all possible (VM-visible) errata
  options enabled. I do that occassionally for testing/analysis, and I
  can imagine this is useful for those building images that are only
  intended to be used in VMs.

I think the change to SOCIONEXT_SYNQUACER_PREITS makes sense given
that's a platform-level detail. Arguably that should be moved into
drivers/irqchip/Kconfig.

Thanks,
Mark.

> ---
>  arch/arm64/Kconfig | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 8d33d7fed6d8549b..81f52f0b988e6350 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -622,6 +622,8 @@ config ARM64_ERRATUM_1542419
>  
>  	  If unsure, say Y.
>  
> +if ARCH_THUNDER2
> +
>  config CAVIUM_ERRATUM_22375
>  	bool "Cavium erratum 22375, 24313"
>  	default y
> @@ -697,6 +699,8 @@ config CAVIUM_TX2_ERRATUM_219
>  
>  	  If unsure, say Y.
>  
> +endif # ARCH_THUNDER2
> +
>  config FUJITSU_ERRATUM_010001
>  	bool "Fujitsu-A64FX erratum E#010001: Undefined fault may occur wrongly"
>  	default y
> @@ -718,6 +722,7 @@ config FUJITSU_ERRATUM_010001
>  
>  config HISILICON_ERRATUM_161600802
>  	bool "Hip07 161600802: Erroneous redistributor VLPI base"
> +	depends on ARCH_HISI
>  	default y
>  	help
>  	  The HiSilicon Hip07 SoC uses the wrong redistributor base
> @@ -726,6 +731,8 @@ config HISILICON_ERRATUM_161600802
>  
>  	  If unsure, say Y.
>  
> +if ARCH_QCOM
> +
>  config QCOM_FALKOR_ERRATUM_1003
>  	bool "Falkor E1003: Incorrect translation due to ASID change"
>  	default y
> @@ -768,8 +775,11 @@ config QCOM_FALKOR_ERRATUM_E1041
>  
>  	  If unsure, say Y.
>  
> +endif # ARCH_QCOM
> +
>  config SOCIONEXT_SYNQUACER_PREITS
>  	bool "Socionext Synquacer: Workaround for GICv3 pre-ITS"
> +	depends on ARCH_SYNQUACER
>  	default y
>  	help
>  	  Socionext Synquacer SoCs implement a separate h/w block to generate
> -- 
> 2.17.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-04-16 12:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16 11:56 [PATCH 0/2] arm64: Vendor-specific errata improvements Geert Uytterhoeven
2020-04-16 11:56 ` [PATCH 1/2] arm64: Sort vendor-specific errata Geert Uytterhoeven
2020-04-16 12:57   ` Mark Rutland
2020-04-16 13:06   ` Arnd Bergmann
2020-05-05 10:58     ` Will Deacon
2020-04-16 11:56 ` [PATCH 2/2] [RFC] arm64: Add dependencies to " Geert Uytterhoeven
2020-04-16 12:56   ` Mark Rutland [this message]
2020-04-16 13:36     ` Arnd Bergmann
2020-04-16 15:38     ` Geert Uytterhoeven
2020-04-16 15:56       ` Mark Rutland
2020-04-16 16:18         ` Geert Uytterhoeven
2020-04-17 15:57   ` Robert Richter

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=20200416125630.GF4987@lakrids.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=agross@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=geert+renesas@glider.be \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rrichter@marvell.com \
    --cc=will@kernel.org \
    --cc=xuwei5@hisilicon.com \
    --cc=yamada.masahiro@socionext.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).