mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Suzuki K Poulose <Suzuki.Poulose@arm.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org,
	Andre Przywara <andre.przywara@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: Run enable method for errata work arounds on late CPUs
Date: Wed, 17 Jan 2018 14:52:09 +0000	[thread overview]
Message-ID: <0872cba5-3dcd-3453-947a-481aa0483af0@arm.com> (raw)
In-Reply-To: <20180117143816.GF22781@e103592.cambridge.arm.com>

On 17/01/18 14:38, Dave Martin wrote:
> On Wed, Jan 17, 2018 at 01:22:19PM +0000, Suzuki K Poulose wrote:
>> On 17/01/18 12:25, Dave Martin wrote:
>>> On Wed, Jan 17, 2018 at 10:05:56AM +0000, Suzuki K Poulose wrote:
>>>> When a CPU is brought up after we have finalised the system
>>>> wide capabilities (i.e, features and errata), we make sure the
>>>> new CPU doesn't need a new errata work around which has not been
>>>> detected already. However we don't run enable() method on the new
>>>> CPU for the errata work arounds already detected. This could
>>>> cause the new CPU running without potential work arounds.
>>>> It is upto the "enable()" method to decide if this CPU should
>>>> do something about the errata.
>>>>
>>>> Fixes: commit 6a6efbb45b7d95c84 ("arm64: Verify CPU errata work arounds on hotplugged CPU")
>>>> Cc: Will Deacon <will.deacon@arm.com>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Andre Przywara <andre.przywara@arm.com>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> Cc: Dave Martin <dave.martin@arm.com>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> ---
>>>>   arch/arm64/kernel/cpu_errata.c | 9 ++++++---
>>>>   1 file changed, 6 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
>>>> index 90a9e465339c..54e41dfe41f6 100644
>>>> --- a/arch/arm64/kernel/cpu_errata.c
>>>> +++ b/arch/arm64/kernel/cpu_errata.c
>>>> @@ -373,15 +373,18 @@ void verify_local_cpu_errata_workarounds(void)
>>>>   {
>>>>   	const struct arm64_cpu_capabilities *caps = arm64_errata;
>>>> -	for (; caps->matches; caps++)
>>>> -		if (!cpus_have_cap(caps->capability) &&
>>>> -			caps->matches(caps, SCOPE_LOCAL_CPU)) {
>>>> +	for (; caps->matches; caps++) {
>>>> +		if (cpus_have_cap(caps->capability)) {
>>>> +			if (caps->enable)
>>>> +				caps->enable((void *)caps);
>>>
>>> Do we really need this cast?
>>
>> Yes, otherwise we would be passing a "const *" where a "void *" is expected,
>> and the compiler warns. Or we could simply change the prototype of the
>> enable() method to accept a const capability ptr.
> 
> Hmmm, what is this argument for exactly?  cpufeature.h doesn't explain
> what it is.

This was introduced by commit 0a0d111d40fd1 ("arm64: cpufeature: Pass capability
structure to ->enable callback").

The idea is to enable multiple entries in the table for a single capability.
Some capabilities (read errata) could be detected in multiple ways. e.g, different
MIDR ranges. (e.g, ARM64_HARDEN_BRANCH_PREDICTOR, ARM64_WORKAROUND_QCOM_FALKOR_E1003.
Now, even though the errata is the same, there might be different work arounds
for them in each "matching" cases. So, we need the "caps" passed on to the
enable() method to see if the "specific work around" should be applied
to the system/CPU (since CPU hwcap could be set by one of the cpu_capabilities
entry.) (as we invoke enable() for all "available" capabilities.)

Passing the caps information makes it easier to decide, by using the caps->matches().

> 
> Does any enable method use this for anything other than a struct
> arm64_cpu_capabilities const * ?

No, we use it only for const struct arm64_cpu_capability *.

> If not, it would be better to specifiy that.

Yes, that could be done.

Cheers
Suzuki

  reply	other threads:[~2018-01-17 14:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-17 10:05 Suzuki K Poulose
2018-01-17 12:25 ` Dave Martin
2018-01-17 13:20   ` Robin Murphy
2018-01-17 13:31     ` Suzuki K Poulose
2018-01-17 13:43       ` Robin Murphy
2018-01-17 14:04         ` Suzuki K Poulose
2018-01-17 13:22   ` Suzuki K Poulose
2018-01-17 14:38     ` Dave Martin
2018-01-17 14:52       ` Suzuki K Poulose [this message]
2018-01-17 16:29         ` Dave Martin

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=0872cba5-3dcd-3453-947a-481aa0483af0@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@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

all inboxes | Powered by JetHome®