All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki.Poulose@arm.com (Suzuki K. Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 2/5] irqchip, gicv3: Workaround for Cavium ThunderX erratum 23154
Date: Tue, 08 Sep 2015 10:09:30 +0100	[thread overview]
Message-ID: <55EEA5CA.5050901@arm.com> (raw)
In-Reply-To: <20150908090023.GB14550@e104818-lin.cambridge.arm.com>

On 08/09/15 10:00, Catalin Marinas wrote:
> On Mon, Sep 07, 2015 at 06:41:50PM +0100, Suzuki K. Poulose wrote:
>> On 07/09/15 18:15, Catalin Marinas wrote:
>>> On Mon, Sep 07, 2015 at 05:54:06PM +0100, Suzuki K. Poulose wrote:
>>>> On 14/08/15 19:28, Robert Richter wrote:
>>>>> +static void gicv3_enable_quirks(void)
>>>>> +{
>>>>> +	if (cpus_have_cap(ARM64_WORKAROUND_CAVIUM_23154))
>>>>> +		static_key_slow_inc(&is_cavium_thunderx);
>>>>
>>>> May be you could use the enable() method added to struct arm64_cpu_capability
>>>> here to perform the above operation, added by James :
>>>>
>>>> commit 1c0763037f1e1caef739e36e09c6d41ed7b61b2d
>>>> Author: James Morse <james.morse@arm.com>
>>>> Date:   Tue Jul 21 13:23:28 2015 +0100
>>>>
>>>>      arm64: kernel: Add cpufeature 'enable' callback
>>>
>>> I thought about this as well when looking at the patch but decided it's
>>> better as it is. The "enable" method is meant to enable per-CPU features
>>> (or workarounds) but here it is about GICv3, so we don't want to enable
>>> for every CPU.
>>
>> Right. I have been playing with a series where the checks are delayed until
>> all CPUs are brought up.
>
> Unrelated to the GIC workaround, delaying the enable feature until the
> CPUs are brought up is not always be feasible.

Right. But then, enabling a feature(and applying the alternatives) based on
a single CPU may not be safe, always, like PAN. If one of the boot time CPU
doesn't have it, then we are in trouble (even though we WARN about it from
SANITY check)

> At some point we may
> implement support to defer the CPU on to user space (I already have a
> patch that does this when no DT enable-method is specified, but I won't
> publish it before Qualcomm fixes its firmware ;)). But we may have other
> reasons to start with CPUs hot-unplugged by default and turn them on
> later.

We have SANITY check infrastructure that WARNs in such cases, if the features
don't match.  But still, wouldn't it be better to enable a feature
only if all the boot-time enabled CPUs have it ? (Errata is an exception though,
which only depends on whether one of the CPU needs it).

Thanks
Suzuki

>

WARNING: multiple messages have this Message-ID (diff)
From: "Suzuki K. Poulose" <Suzuki.Poulose@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Robert Richter <rric@kernel.org>,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Robert Richter <rrichter@cavium.com>,
	Tirumalesh Chalamarla <tchalamarla@cavium.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 2/5] irqchip, gicv3: Workaround for Cavium ThunderX erratum 23154
Date: Tue, 08 Sep 2015 10:09:30 +0100	[thread overview]
Message-ID: <55EEA5CA.5050901@arm.com> (raw)
In-Reply-To: <20150908090023.GB14550@e104818-lin.cambridge.arm.com>

On 08/09/15 10:00, Catalin Marinas wrote:
> On Mon, Sep 07, 2015 at 06:41:50PM +0100, Suzuki K. Poulose wrote:
>> On 07/09/15 18:15, Catalin Marinas wrote:
>>> On Mon, Sep 07, 2015 at 05:54:06PM +0100, Suzuki K. Poulose wrote:
>>>> On 14/08/15 19:28, Robert Richter wrote:
>>>>> +static void gicv3_enable_quirks(void)
>>>>> +{
>>>>> +	if (cpus_have_cap(ARM64_WORKAROUND_CAVIUM_23154))
>>>>> +		static_key_slow_inc(&is_cavium_thunderx);
>>>>
>>>> May be you could use the enable() method added to struct arm64_cpu_capability
>>>> here to perform the above operation, added by James :
>>>>
>>>> commit 1c0763037f1e1caef739e36e09c6d41ed7b61b2d
>>>> Author: James Morse <james.morse@arm.com>
>>>> Date:   Tue Jul 21 13:23:28 2015 +0100
>>>>
>>>>      arm64: kernel: Add cpufeature 'enable' callback
>>>
>>> I thought about this as well when looking at the patch but decided it's
>>> better as it is. The "enable" method is meant to enable per-CPU features
>>> (or workarounds) but here it is about GICv3, so we don't want to enable
>>> for every CPU.
>>
>> Right. I have been playing with a series where the checks are delayed until
>> all CPUs are brought up.
>
> Unrelated to the GIC workaround, delaying the enable feature until the
> CPUs are brought up is not always be feasible.

Right. But then, enabling a feature(and applying the alternatives) based on
a single CPU may not be safe, always, like PAN. If one of the boot time CPU
doesn't have it, then we are in trouble (even though we WARN about it from
SANITY check)

> At some point we may
> implement support to defer the CPU on to user space (I already have a
> patch that does this when no DT enable-method is specified, but I won't
> publish it before Qualcomm fixes its firmware ;)). But we may have other
> reasons to start with CPUs hot-unplugged by default and turn them on
> later.

We have SANITY check infrastructure that WARNs in such cases, if the features
don't match.  But still, wouldn't it be better to enable a feature
only if all the boot-time enabled CPUs have it ? (Errata is an exception though,
which only depends on whether one of the CPU needs it).

Thanks
Suzuki

>


  reply	other threads:[~2015-09-08  9:09 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-14 18:28 [PATCH v4 0/5] irqchip, gicv3: Updates and Cavium ThunderX errata workarounds Robert Richter
2015-08-14 18:28 ` Robert Richter
2015-08-14 18:28 ` [PATCH v4 1/5] irqchip, gicv3-its: Add range check for number of allocated pages Robert Richter
2015-08-14 18:28   ` Robert Richter
2015-08-14 18:28 ` [PATCH v4 2/5] irqchip, gicv3: Workaround for Cavium ThunderX erratum 23154 Robert Richter
2015-08-14 18:28   ` Robert Richter
2015-08-17 16:40   ` Catalin Marinas
2015-08-17 16:40     ` Catalin Marinas
2015-08-19 15:43     ` Robert Richter
2015-08-19 15:43       ` Robert Richter
2015-08-17 17:00   ` David Daney
2015-08-17 17:00     ` David Daney
2015-08-19 16:05     ` Robert Richter
2015-08-19 16:05       ` Robert Richter
2015-09-07 16:54   ` Suzuki K. Poulose
2015-09-07 16:54     ` Suzuki K. Poulose
2015-09-07 17:09     ` Marc Zyngier
2015-09-07 17:09       ` Marc Zyngier
2015-09-07 17:32       ` Robert Richter
2015-09-07 17:32         ` Robert Richter
2015-09-07 17:15     ` Catalin Marinas
2015-09-07 17:15       ` Catalin Marinas
2015-09-07 17:41       ` Suzuki K. Poulose
2015-09-07 17:41         ` Suzuki K. Poulose
2015-09-08  9:00         ` Catalin Marinas
2015-09-08  9:00           ` Catalin Marinas
2015-09-08  9:09           ` Suzuki K. Poulose [this message]
2015-09-08  9:09             ` Suzuki K. Poulose
2015-09-08  9:37             ` Catalin Marinas
2015-09-08  9:37               ` Catalin Marinas
2015-09-08 10:30               ` Suzuki K. Poulose
2015-09-08 10:30                 ` Suzuki K. Poulose
2015-08-14 18:28 ` [PATCH v4 3/5] irqchip, gicv3-its: Read typer register outside the loop Robert Richter
2015-08-14 18:28   ` Robert Richter
2015-08-14 18:28 ` [PATCH v4 4/5] irqchip, gicv3-its: Add HW revision detection and configuration Robert Richter
2015-08-14 18:28   ` Robert Richter
2015-09-07 16:26   ` Marc Zyngier
2015-09-07 16:26     ` Marc Zyngier
2015-08-14 18:28 ` [PATCH v4 5/5] irqchip, gicv3-its: Workaround for Cavium ThunderX errata 22375, 24313 Robert Richter
2015-08-14 18:28   ` Robert Richter
2015-09-07 16:32   ` Marc Zyngier
2015-09-07 16:32     ` Marc Zyngier
2015-09-18  8:33     ` Robert Richter
2015-09-18  8:33       ` Robert Richter
2015-09-07 16:35 ` [PATCH v4 0/5] irqchip, gicv3: Updates and Cavium ThunderX errata workarounds Marc Zyngier
2015-09-07 16:35   ` 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=55EEA5CA.5050901@arm.com \
    --to=suzuki.poulose@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.