From: "Huang, Tao" <huangtao@rock-chips.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Caesar Wang <wxt@rock-chips.com>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Heiko Stuebner <heiko@sntech.de>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
sjg@chromium.org, Stephen Boyd <sboyd@codeaurora.org>,
dianders@chromium.org, linux-kernel@vger.kernel.org,
Nadav Haklai <nadavh@marvell.com>,
linux-rockchip@lists.infradead.org, cwz@rock-chips.com,
Jonathan Stone <j.stone@samsung.com>,
Gregory CLEMENT <gregory.clement@free-electrons.com>,
linux-arm-kernel@lists.infradead.org, hl@rock-chips.com
Subject: Re: [RESEND PATCH 0/1] Fix the "hard LOCKUP" when running a heavy loading
Date: Tue, 3 Nov 2015 20:00:06 +0800 [thread overview]
Message-ID: <5638A1C6.30200@rock-chips.com> (raw)
In-Reply-To: <20151103111437.GU8644@n2100.arm.linux.org.uk>
Hello Russell:
在 2015年11月03日 19:14, Russell King - ARM Linux 写道:
> On Tue, Nov 03, 2015 at 04:10:08PM +0800, Caesar Wang wrote:
>> As the Russell said:
>> "in other words, which can be handled by updating a control register in
>> the firmware or boot loader"
>> Maybe the better solution is in firmware.
>
> The full quote is:
>
> "I think we're at the point where we start insisting that workarounds
> which are simple enable/disable feature bit operations (in other words,
> which can be handled by updating a control register in the firmware or
> boot loader) must be done that way, and we are not going to add such
> workarounds to the kernel anymore."
>
> The position hasn't changed. Workarounds such as this should be handled
> in the firmware/boot loader before control is passed to the kernel.
>
> The reason is very simple: if the C compiler can generate code which
> triggers the bug, it can generate code which triggers the bug in the
> boot loader. So, the only place such workarounds can be done is before
> any C code gets executed. Putting such workarounds in the kernel is
> completely inappropriate.
I agree with your reason for CPU0. But how about CPU1~3 if we don't use
any firmware such as ARM Trusted Firmware to take control of CPU power
on? If the CPU1~3 will run on Linux when its first instruction is running?
BTW I don't want to argue with you the workaround is right or wrong
because I know the errata just happen on r0p0 not r0p1.
>
> Sorry, I'm not going to accept this workaround into the kernel.
It seems we should introduce some code outside the kernel to do such
initialization?
WARNING: multiple messages have this Message-ID (diff)
From: huangtao@rock-chips.com (Huang, Tao)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH 0/1] Fix the "hard LOCKUP" when running a heavy loading
Date: Tue, 3 Nov 2015 20:00:06 +0800 [thread overview]
Message-ID: <5638A1C6.30200@rock-chips.com> (raw)
In-Reply-To: <20151103111437.GU8644@n2100.arm.linux.org.uk>
Hello Russell:
? 2015?11?03? 19:14, Russell King - ARM Linux ??:
> On Tue, Nov 03, 2015 at 04:10:08PM +0800, Caesar Wang wrote:
>> As the Russell said:
>> "in other words, which can be handled by updating a control register in
>> the firmware or boot loader"
>> Maybe the better solution is in firmware.
>
> The full quote is:
>
> "I think we're at the point where we start insisting that workarounds
> which are simple enable/disable feature bit operations (in other words,
> which can be handled by updating a control register in the firmware or
> boot loader) must be done that way, and we are not going to add such
> workarounds to the kernel anymore."
>
> The position hasn't changed. Workarounds such as this should be handled
> in the firmware/boot loader before control is passed to the kernel.
>
> The reason is very simple: if the C compiler can generate code which
> triggers the bug, it can generate code which triggers the bug in the
> boot loader. So, the only place such workarounds can be done is before
> any C code gets executed. Putting such workarounds in the kernel is
> completely inappropriate.
I agree with your reason for CPU0. But how about CPU1~3 if we don't use
any firmware such as ARM Trusted Firmware to take control of CPU power
on? If the CPU1~3 will run on Linux when its first instruction is running?
BTW I don't want to argue with you the workaround is right or wrong
because I know the errata just happen on r0p0 not r0p1.
>
> Sorry, I'm not going to accept this workaround into the kernel.
It seems we should introduce some code outside the kernel to do such
initialization?
next prev parent reply other threads:[~2015-11-03 12:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-03 8:10 [RESEND PATCH 0/1] Fix the "hard LOCKUP" when running a heavy loading Caesar Wang
2015-11-03 8:10 ` Caesar Wang
2015-11-03 8:10 ` Caesar Wang
[not found] ` <1446538209-13490-1-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2015-11-03 8:10 ` [RESEND PATCH] ARM: errata: Workaround for Cortex-A12 erratum 818325 Caesar Wang
2015-11-03 8:10 ` Caesar Wang
2015-11-03 8:10 ` Caesar Wang
[not found] ` <1446538209-13490-2-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2015-11-03 8:45 ` Arnd Bergmann
2015-11-03 8:45 ` Arnd Bergmann
2015-11-03 8:45 ` Arnd Bergmann
2015-11-03 9:04 ` Caesar Wang
2015-11-03 9:04 ` Caesar Wang
2015-11-03 9:04 ` Caesar Wang
2015-11-03 10:21 ` kbuild test robot
2015-11-03 10:21 ` kbuild test robot
2015-11-03 10:21 ` kbuild test robot
2015-11-03 10:41 ` [PATCH v1] " Caesar Wang
2015-11-03 10:41 ` Caesar Wang
2015-11-03 11:14 ` [RESEND PATCH 0/1] Fix the "hard LOCKUP" when running a heavy loading Russell King - ARM Linux
2015-11-03 11:14 ` Russell King - ARM Linux
2015-11-03 12:00 ` Huang, Tao [this message]
2015-11-03 12:00 ` Huang, Tao
2015-11-03 11:30 ` Will Deacon
2015-11-03 11:30 ` Will Deacon
2015-11-03 19:00 ` Doug Anderson
2015-11-03 19:00 ` Doug Anderson
2015-11-06 12:17 ` Will Deacon
2015-11-06 12:17 ` Will Deacon
2015-11-09 4:39 ` Doug Anderson
2015-11-09 4:39 ` Doug Anderson
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=5638A1C6.30200@rock-chips.com \
--to=huangtao@rock-chips.com \
--cc=ard.biesheuvel@linaro.org \
--cc=cwz@rock-chips.com \
--cc=dianders@chromium.org \
--cc=gregory.clement@free-electrons.com \
--cc=heiko@sntech.de \
--cc=hl@rock-chips.com \
--cc=j.stone@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=nadavh@marvell.com \
--cc=sboyd@codeaurora.org \
--cc=sjg@chromium.org \
--cc=thomas.petazzoni@free-electrons.com \
--cc=wxt@rock-chips.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 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.