Re: [PATCH RFC 0/6] PSCI-via-EFI to support firmware and kernel sharing EL2 for Apple Silicon

[Will Deacon <will@kernel.org>]

On Thu, Sep 03, 2026 at 12:42:39PM +0100, Mark Rutland wrote:
> On Thu, Sep 03, 2026 at 01:34:56PM +0200, Ard Biesheuvel wrote:
> > On Wed, 8 Jul 2026, at 09:15, Sven Peter wrote:
> > > This series adds a custom EFI table that points to a PSCI entry point
> > > (plus some other stuff that has to be available before EFI runtime
> > > services are set up) and adds support for this new conduit to the psci
> > > code. We can't directly use the normal EFI runtime path because that one
> > > takes a sleeping lock and we need to be able to call into PSCI from
> > > atomic context during e.g. cpu bringup or during idle.
> > > It also adds support for specifying the specific MAIR attributes for EFI
> > > runtime mappings as defined in the latest UEFI spec since Apple Silicon
> > > is rather allergic to using Device-nGnRnE vs. Device-nGnRE for its MMIO.
> 
> > >       dt-bindings: arm: psci: Add EFI conduit
> > >       arm64/efi: Add and parse custom PSCI EFI configuration table
> > >       efi: Add EFI_MEMORY_ISA_{MASK,VALID}
> > >       arm64/efi: Honor EFI_MEMORY_ISA_MASK for Device-nGnRnE vs -nGnRE
> > >       firmware/psci: Add EFI runtime conduit
> > >       arm64: dts: apple: t8103: Add PSCI and CPU idle states
> > >
> > 
> > I've picked up patches #3 and #4, which are useful in their own right.
> > 
> > I'm not sure if the arm64 maintainers will want to consider this, but
> > I think it's a reasonable compromise, as it puts the abstraction in
> > the right place.
> 
> Sorry for the late reply; I've been away almost all of August and I'm
> slowly catching up on things.
> 
> As with last time this was proposed (in abstract), I am not happy about
> bodging an EFI conduit into PSCI, given that the manner in which state
> is managed is completely different from SMCCC.
> 
> If we need a mechanism for doing hotplug and/or idle without HVC/SMC,
> that's one thing we can consider. I don't think we should pretend that
> it is PSCI.

What do you have in mind for an alternative mechanism? I understand your
objection to this proposal, but at least it keeps the interface fairly
high-level and avoids opening the flood gates for a bunch of SoC-specific
idle routines. Are you thinking of extensions to the PSCI spec or
something else?

Will