Re: [PATCH v2 0/2] firmware/psci: Switch to the sys-off handler API

[Samuel Holland]

On 1/25/23 06:53, Dmitry Osipenko wrote:
> On 1/1/23 21:17, Samuel Holland wrote:
>> I want to convert the axp20x PMIC poweroff handler to use the sys-off
>> API, so it can be used as a fallback for the SBI poweroff handler on
>> RISC-V. But the PSCI poweroff handler still uses pm_power_off, so done
>> alone, this conversion would cause the axp20x callback to be called
>> first, before the PSCI poweroff handler.
>>
>> In order to prevent this change in behavior, the PSCI poweroff handler
>> needs to be converted to the sys-off API first, at a higher priority.
>>
>> This series performs the conversion, after accounting for the fact that
>> the PSCI poweroff handler is registered quite early during boot.
>>
>> The first patch is a dependency for both this series and the SBI
>> series[1], so I would like to get at least patch 1 merged soon.
>>
>> [1]: https://lore.kernel.org/lkml/20221228161915.13194-1-samuel@xxxxxxxxxxxx/
>>
>> Changes in v2:
>>  - Update commit messages
>>
>> Samuel Holland (2):
>>   kernel/reboot: Use the static sys-off handler for any priority
>>   firmware/psci: Switch to the sys-off handler API
>>
>>  drivers/firmware/psci/psci.c |  9 ++++++---
>>  kernel/reboot.c              | 10 ++++------
>>  2 files changed, 10 insertions(+), 9 deletions(-)
>>
> 
> Hello Rafael,
> 
> Do you think you will be able to pick up this series for 6.3? I'm going
> to continue removing the pm_power_off from kernel, the new power-off API
> feels stable now to me. I think the Samuel's improvement for the early
> boot memory allocation will be good to have to avoid similar problem for
> other drivers.
> 
> Ideally, the PSCI patch should get an ack, though the code change is
> about the PM stuff, so perhaps will be fine to take it via PM tree if FW
> maintainers will show no interest in the nearest time.

Additionally, a patch which depends on this[1] series has already been
merged[2], so if this series does not make 6.3, that change would need
to be reverted.

Regards,
Samuel

[1]:
https://lore.kernel.org/lkml/20221228162752.14204-1-samuel@xxxxxxxxxxxx/
[2]: https://git.kernel.org/next/linux-next/c/a4755a1374ba