[PATCH] firmware/psci: Fix MEM_PROTECT_RANGE function numbers

Will Deacon will at kernel.org
Fri Jan 6 09:10:39 PST 2023


On Thu, Jan 05, 2023 at 03:53:48PM +0000, Mark Rutland wrote:
> On Thu, Jan 05, 2023 at 03:49:47PM +0000, Marc Zyngier wrote:
> > On Fri, 25 Nov 2022 10:18:26 +0000,
> > Will Deacon <will at kernel.org> wrote:
> > > 
> > > PSCI v1.1 offers 32-bit and 64-bit variants of the MEM_PROTECT_RANGE
> > > call using function identifier 20.
> > > 
> > > Fix the incorrect definitions of the MEM_PROTECT_CHECK_RANGE calls in
> > > the PSCI UAPI header.
> > > 
> > > Cc: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> > > Cc: Mark Rutland <mark.rutland at arm.com>
> > > Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> > > Cc: Arnd Bergmann <arnd at arndb.de>
> > > Fixes: 3137f2e60098 ("firmware/psci: Add debugfs support to ease debugging")
> > > Signed-off-by: Will Deacon <will at kernel.org>
> > > ---
> > >  include/uapi/linux/psci.h | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/include/uapi/linux/psci.h b/include/uapi/linux/psci.h
> > > index 3511095c2702..42a40ad3fb62 100644
> > > --- a/include/uapi/linux/psci.h
> > > +++ b/include/uapi/linux/psci.h
> > > @@ -58,7 +58,7 @@
> > >  
> > >  #define PSCI_1_1_FN_SYSTEM_RESET2		PSCI_0_2_FN(18)
> > >  #define PSCI_1_1_FN_MEM_PROTECT			PSCI_0_2_FN(19)
> > > -#define PSCI_1_1_FN_MEM_PROTECT_CHECK_RANGE	PSCI_0_2_FN(19)
> > > +#define PSCI_1_1_FN_MEM_PROTECT_CHECK_RANGE	PSCI_0_2_FN(20)
> > >  
> > >  #define PSCI_1_0_FN64_CPU_DEFAULT_SUSPEND	PSCI_0_2_FN64(12)
> > >  #define PSCI_1_0_FN64_NODE_HW_STATE		PSCI_0_2_FN64(13)
> > > @@ -67,7 +67,7 @@
> > >  #define PSCI_1_0_FN64_STAT_COUNT		PSCI_0_2_FN64(17)
> > >  
> > >  #define PSCI_1_1_FN64_SYSTEM_RESET2		PSCI_0_2_FN64(18)
> > > -#define PSCI_1_1_FN64_MEM_PROTECT_CHECK_RANGE	PSCI_0_2_FN64(19)
> > > +#define PSCI_1_1_FN64_MEM_PROTECT_CHECK_RANGE	PSCI_0_2_FN64(20)
> > >  
> > >  /* PSCI v0.2 power state encoding for CPU_SUSPEND function */
> > >  #define PSCI_0_2_POWER_STATE_ID_MASK		0xffff
> > 
> > Acked-by: Marc Zyngier <maz at kernel.org>
> 
> Likewise:
> 
>   Acked-by: Mark Rutland <mark.rutland at arm.com>
> 
> > Should this be taken via the arm64 tree, together with [1]?
> 
> Yes please to both being queued via the arm64 tree.
> 
> Sorry for droppnig the ball here.
> 
> Going forward I'll try to be explicit w.r.t. how to queue PSCI bits; I'd be
> happy to route them through arm64 generally if that arm64 maintainers are happy
> with that.

Thanks, I'll sweep these two up as fixes, since I already have a few
pending.

Will



More information about the linux-arm-kernel mailing list