Hi David, > On 26 Sep 2024, at 16:30, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > 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. > Now I see the definition for PSCI_1_3_HIBERNATE_TYPE_OFF was misleading for me when BIT(PSCI_1_3_HIBERNATE_TYPE_OFF) works for both discovery and as argument for SYSTEM_OFF2. The common factor being the bit offset in the bitmap for SYSTEM_OFF2 discovery and argument to call SYSTEM_OFF2 as well. Would it be clearer something like: #define PSCI_1_3_HIBERNATE_TYPE_OFF BIT(0) Assuming future definitions would keep the same common factor can be helpful, however please let me know whether I am missing something. Thanks, Miguel > 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? >
