All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/5] arm64: cpufeature: Add scope for capability check
Date: Fri, 15 Apr 2016 13:55:12 +0100	[thread overview]
Message-ID: <20160415125511.GF22906@arm.com> (raw)
In-Reply-To: <570FD7C2.9030305@arm.com>

On Thu, Apr 14, 2016 at 06:47:46PM +0100, Suzuki K Poulose wrote:
> On 14/04/16 18:38, Will Deacon wrote:
> >Hi Suzuki,
> >
> >On Wed, Apr 06, 2016 at 12:24:10PM +0100, Suzuki K Poulose wrote:
> >>Add scope parameter to the arm64_cpu_capabilities::matches(),
> >>so that this can be reused for checking the capability on a
> >>given CPU vs the system wide. By default, the system uses
> >>'system' wide values for setting the CPU_HWCAPs and ELF_HWCAPs.
> 
> >>  static bool __maybe_unused
> >>-is_affected_midr_range(const struct arm64_cpu_capabilities *entry)
> >>+is_affected_midr_range(const struct arm64_cpu_capabilities *entry, int __unused)
> >
> >Maybe it would be better to WARN if somebody passes SCOPE_SYSTEM, rather
> >than silently treat it as per-cpu?
> 
> Should we worry about errata's which may not necessarily depend on per CPU or
> a local capability (GIC) ?

Why would they be calling is_affected_midr_range?

> If not, we could add a WARN after passing down LOCAL
> scope for errata.

But if we don't care about errata that aren't local, then why would we warn
on LOCAL?

> Right now we always do SCOPE_SYSTEM from update_cpu_capabilities(), even for
> cpu_errata table. There is no specific reason for that.

I'm totally confused. Can you define SCOPE_SYSTEM and SCOPE_LOCAL for me,
please?

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Suzuki K Poulose <Suzuki.Poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, marc.zyngier@arm.com,
	catalin.marinas@arm.com, mark.rutland@arm.com,
	Vadim.Lomovtsev@caviumnetworks.com,
	James Morse <james.morse@arm.com>,
	Andre Przywara <andre.przywara@arm.com>
Subject: Re: [PATCH 1/5] arm64: cpufeature: Add scope for capability check
Date: Fri, 15 Apr 2016 13:55:12 +0100	[thread overview]
Message-ID: <20160415125511.GF22906@arm.com> (raw)
In-Reply-To: <570FD7C2.9030305@arm.com>

On Thu, Apr 14, 2016 at 06:47:46PM +0100, Suzuki K Poulose wrote:
> On 14/04/16 18:38, Will Deacon wrote:
> >Hi Suzuki,
> >
> >On Wed, Apr 06, 2016 at 12:24:10PM +0100, Suzuki K Poulose wrote:
> >>Add scope parameter to the arm64_cpu_capabilities::matches(),
> >>so that this can be reused for checking the capability on a
> >>given CPU vs the system wide. By default, the system uses
> >>'system' wide values for setting the CPU_HWCAPs and ELF_HWCAPs.
> 
> >>  static bool __maybe_unused
> >>-is_affected_midr_range(const struct arm64_cpu_capabilities *entry)
> >>+is_affected_midr_range(const struct arm64_cpu_capabilities *entry, int __unused)
> >
> >Maybe it would be better to WARN if somebody passes SCOPE_SYSTEM, rather
> >than silently treat it as per-cpu?
> 
> Should we worry about errata's which may not necessarily depend on per CPU or
> a local capability (GIC) ?

Why would they be calling is_affected_midr_range?

> If not, we could add a WARN after passing down LOCAL
> scope for errata.

But if we don't care about errata that aren't local, then why would we warn
on LOCAL?

> Right now we always do SCOPE_SYSTEM from update_cpu_capabilities(), even for
> cpu_errata table. There is no specific reason for that.

I'm totally confused. Can you define SCOPE_SYSTEM and SCOPE_LOCAL for me,
please?

Will

  reply	other threads:[~2016-04-15 12:55 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-06 11:24 [PATCH 0/5] arm64: Fix behavior of maxcpus=n Suzuki K Poulose
2016-04-06 11:24 ` Suzuki K Poulose
2016-04-06 11:24 ` [PATCH 1/5] arm64: cpufeature: Add scope for capability check Suzuki K Poulose
2016-04-06 11:24   ` Suzuki K Poulose
2016-04-14 17:38   ` Will Deacon
2016-04-14 17:38     ` Will Deacon
2016-04-14 17:47     ` Suzuki K Poulose
2016-04-14 17:47       ` Suzuki K Poulose
2016-04-15 12:55       ` Will Deacon [this message]
2016-04-15 12:55         ` Will Deacon
2016-04-15 13:26         ` Suzuki K Poulose
2016-04-15 13:26           ` Suzuki K Poulose
2016-04-06 11:24 ` [PATCH 2/5] arm64: Allow a capability to be checked on a single CPU Suzuki K Poulose
2016-04-06 11:24   ` Suzuki K Poulose
2016-04-06 11:24 ` [PATCH 3/5] irqchip/gic: Restore CPU interface checking Suzuki K Poulose
2016-04-06 11:24   ` Suzuki K Poulose
2016-04-06 11:24 ` [PATCH 4/5] arm64: Verify CPU errata work arounds on hotplugged CPU Suzuki K Poulose
2016-04-06 11:24   ` Suzuki K Poulose
2016-04-14 17:39   ` Will Deacon
2016-04-14 17:39     ` Will Deacon
2016-04-14 17:49     ` Suzuki K Poulose
2016-04-14 17:49       ` Suzuki K Poulose
2016-04-15 14:10       ` Suzuki K Poulose
2016-04-15 14:10         ` Suzuki K Poulose
2016-04-15 14:12         ` Will Deacon
2016-04-15 14:12           ` Will Deacon
2016-04-18 13:41           ` Suzuki K Poulose
2016-04-18 13:41             ` Suzuki K Poulose
2016-04-06 11:24 ` [PATCH 5/5] arm64: Fix behavior of maxcpus=N Suzuki K Poulose
2016-04-06 11:24   ` Suzuki K Poulose
2016-04-07  9:18   ` James Morse
2016-04-07  9:18     ` James Morse
2016-04-07  9:26     ` Suzuki K Poulose
2016-04-07  9:26       ` Suzuki K Poulose
2016-04-07 10:07     ` [UPDATED] " Suzuki K Poulose
2016-04-07 10:07       ` Suzuki K Poulose

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=20160415125511.GF22906@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.