Re: [PATCH v2 5/6] arm: Use armv8_switch_to_el1 env to switch to EL1

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]

On Fri, Sep 03, 2021 at 11:19:28AM +0100, Peter Hoyes wrote:
> 
> Hi,
> 
> On 03/09/2021 00:49, Tom Rini wrote:
> > On Fri, Sep 03, 2021 at 12:07:20AM +0100, Andre Przywara wrote:
> > > On Thu, 2 Sep 2021 18:42:05 -0400
> > > Tom Rini <trini@konsulko.com> wrote:
> > > 
> > > Hi Tom,
> > > 
> > > > On Thu, Aug 19, 2021 at 04:53:13PM +0100, Peter Hoyes wrote:
> > > > 
> > > > > From: Peter Hoyes <Peter.Hoyes@arm.com>
> > > > > 
> > > > > Use the environment variable armv8_switch_to_el1 to determine whether
> > > > > to switch to EL1 at runtime. This is an alternative to the
> > > > > CONFIG_ARMV8_SWITCH_TO_EL1 compile-time option.
> > > > > 
> > > > > The environment variable will be ineffective if the ARMV8_MULTIENTRY
> > > > > config is used.
> > > > > 
> > > > > This is required by the Armv8r64 architecture, which must be able to
> > > > > boot at S-EL1 for Linux but may need to boot at other ELs for other
> > > > > systems.
> > > > > 
> > > > > Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
> > > > Applied to u-boot/next, thanks!
> > > Sorry for keeping silent on this, we had some internal discussions
> > > here, and we don't think this is the right approach.
> > Well, oops on my part too.
> Oops here too.
> > 
> > > This whole CONFIG_ARMV8_SWITCH_TO_EL1 solution is actually already
> > > questionable, as it goes somewhat against the PSCI spec, which requires
> > > secondaries to enter in the highest non-secure exception level (Section
> > > 6.1.3: "... As described in Figure 6, the return Exception level for a
> > > CPU_ON call is the highest Non secure Exception level implemented.")
> > > 
> > > In any case the primary core must enter an the same exception level as
> > > the secondaries, or all hell breaks loose. The current code violates
> > > this bluntly when the dynamic method is used (as the spin table code
> > > doesn't know about this variable).
> > > 
> > > So can you please revert this patch? We are looking into a different
> > Should I undo just this, or the whole vexpress_aemv8r series?
> > 
> We are still discussing how to support v8-R internally and it'll probably
> take a while to resolve.
> 
> Please can you revert the wholeseries apart from patch 1, which isn't
> actually specific to the v8-R. (If preferable,I can submit a "v3" to
> clarify this).

OK, I'll revert everything except the first patch.  For the next
go-round, I had fixed up that the defconfig wasn't listed in the board
MAINTAINERS, and there was a typo in the docs that checkpatch also
spotted.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]