[PATCH v4 1/6] firmware/psci: Add definitions for PSCI v1.3 specification

[David Woodhouse]

On Thu, 2024-09-26 at 09:56 +0000, Miguel Luis wrote:
> 
> > +/* PSCI v1.3 hibernate type for SYSTEM_OFF2 */
> > +#define PSCI_1_3_HIBERNATE_TYPE_OFF 0
> 
> Should it be 1 as hibernate type?

It is in discovery, as BIT(PSCI_1_3_HIBERNATE_TYPE_OFF) == 1<<0 == 1.

But using a bitmask was only supposed to be for the discovery with
PSCI_FEATURES, as that has to advertise all the available hibernation
types.

The actual SYSTEM_OFF2 call was supposed to just take the numeric value
as an argument, since obviously *that* one isn't a bitmask. 

Except... I see that now the spec has finally been updated, it seems to
say that 0x1 is the value to pass to the SYSTEM_OFF2 call for
HIBERNATE_OFF, not 0x0. Which doesn't seem to make much sense, and I
don't recall it being what we discussed. Souvik, what happened there?

My understanding was that for each supported hibernation type #n, for
which HIBERERNATE_OFF is zero), the PSCI_FEATURES query would include
the bit (1<<n) to indicate that it is supported, and then the actual
SYSTEM_OFF2 call parameter would be (n) itself, precisely as
implemented here.

But the spec now seems to say that HIBERNATE_OFF is advertised as
(1<<0) in PSCI_FEATURES, but invoked with the value (1).

Is it too late to fix?

If it isn't just a thinko, what is the intent in the current spec?

If we have new hibernate types such that

 #define PSCI_1_3_HIBERNATE_TYPE_OFF 0
 #define PSCI_1_3_HIBERNATE_TYPE_FOO 1
 #define PSCI_1_3_HIBERNATE_TYPE_BAR 2

It seems obvious that the PSCI_FEATURES response will contain (1<<0),
(1<<1) and (1<<2) for them respectively, but what is supposed to be
passed to the actual SYSTEM_OFF2 call? Is it always just going to be
(PSCI_1_3_HIBERNATE_TYPE_xxx + 1)?

I think we should just fix §5.1.10 to report that 0x0 is HIBERNATE_OFF,
yes?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240926/06583092/attachment.p7s>