Re: [PATCH v8 00/27] Introduce power-off+restart call chain API

2022-05-24 Thread Rafael J. Wysocki
Hi Geert,

On Mon, May 23, 2022 at 8:08 PM Geert Uytterhoeven  wrote:
>
> Hi Rafael,
>
> On Wed, May 18, 2022 at 4:46 PM Rafael J. Wysocki  wrote:
> > On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
> >  wrote:
>
> > >   m68k: Switch to new sys-off handler API
>
> Sorry, I didn't realize this was going to interact with the new m68k
> virtual machine support, which is included in the m68k pull request
> for v5.19.
>
> > However, I'm going to send a pull request with it in the second half
> > of the merge window, after the majority of the other changes in the
> > subsystems touched by it have been integrated.
>
> And presumably you will have to merge in v5.19-rc1, too?

I will merge this series on top of the Linus' merges of my pull
requests sent yesterday (assuming that he pulls them, that is).

> I've sent a fix.  It should appear at
> https://lore.kernel.org/r/20220523175520.949681-1-ge...@linux-m68k.org
> soon.
>
> Can you please include that in your PR?

I will.

Thanks!



Re: [PATCH v8 00/27] Introduce power-off+restart call chain API

2022-05-24 Thread Geert Uytterhoeven
Hi Rafael,

On Wed, May 18, 2022 at 4:46 PM Rafael J. Wysocki  wrote:
> On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
>  wrote:

> >   m68k: Switch to new sys-off handler API

Sorry, I didn't realize this was going to interact with the new m68k
virtual machine support, which is included in the m68k pull request
for v5.19.

> However, I'm going to send a pull request with it in the second half
> of the merge window, after the majority of the other changes in the
> subsystems touched by it have been integrated.

And presumably you will have to merge in v5.19-rc1, too?

I've sent a fix.  It should appear at
https://lore.kernel.org/r/20220523175520.949681-1-ge...@linux-m68k.org
soon.

Can you please include that in your PR?
Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds



Re: [PATCH v8 00/27] Introduce power-off+restart call chain API

2022-05-19 Thread Dmitry Osipenko
On 5/18/22 17:46, Rafael J. Wysocki wrote:
> On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
>  wrote:
...
>> Introduce new API that provides call chains support for all restart and
>> power-off modes. The new API is designed with simplicity and extensibility
>> in mind.
...
> The v8 looks much better than the previous versions to me.
> 
> I actually don't really have any comments on it except for the minor
> remark regarding patch [1/27] sent separately.
> 
> Please just send an update of that one patch and I will queue up the
> series for 5.19.
> 
> However, I'm going to send a pull request with it in the second half
> of the merge window, after the majority of the other changes in the
> subsystems touched by it have been integrated.

Thanks, Rafael. I sent out the updated [1/27] patch to you.

For the reference, the updated patch can be found here as well:

https://lore.kernel.org/all/20220519105015.1195955-1-dmitry.osipe...@collabora.com/T/#u

-- 
Best regards,
Dmitry



Re: [PATCH v8 00/27] Introduce power-off+restart call chain API

2022-05-18 Thread Rafael J. Wysocki
On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
 wrote:
>
> Problem
> ---
>
> SoC devices require power-off call chaining functionality from kernel.
> We have a widely used restart chaining provided by restart notifier API,
> but nothing for power-off.
>
> Solution
> 
>
> Introduce new API that provides call chains support for all restart and
> power-off modes. The new API is designed with simplicity and extensibility
> in mind.
>
> This is a third attempt to introduce the new API. First was made by
> Guenter Roeck back in 2014, second was made by Thierry Reding in 2017.
> In fact the work didn't stop and recently arm_pm_restart() was removed
> from v5.14 kernel, which was a part of preparatory work started by
> Guenter Roeck.
>
> Adoption plan
> -
>
> This patchset introduces the new API. It also converts multiple drivers
> and arch code to the new API to demonstrate how it all looks in practice,
> removing the pm_power_off_prepare global variable.
>
> The plan is:
>
> 1. Merge the new API and convert arch code to use do_kernel_power_off().
>For now the new API will co-exist with the older API.
>
> 2. Convert all drivers and platform code to the new API.
>
> 3. Remove obsoleted pm_power_off and pm_power_off_prepare variables.
>
> Results
> ---
>
> 1. Devices can be powered off properly.
>
> 2. Global variables are removed from drivers.
>
> 3. Global pm_power_off and pm_power_off_prepare callback variables are
> removed once all users are converted to the new API. The latter callback
> is removed by patch #24 of this series.
>
> 4. Ambiguous call chain ordering is prohibited for non-default priorities.
>
> Changelog:
>
> v8: - Reworked sys-off handler like was suggested by Rafael Wysocki in
>   the comments to v7.
>
> - The struct sys-off handler now is private to kernel/reboot.c and
>   new API is simplified.
>
> - There is a single sys-off API function for all handler types.
>   Users shall pass the required sys-off mode type (restart, power-off
>   and etc).
>
> - There is single struct sys_off_data callback argument for all
>   handler modes.
>
> - User's callback now must return NOTIFY_DONE or NOTIFY_STOP.
>
> - The default priority level is zero now.
>
> - Multiple handlers now allowed to be registered at the default
>   priority level.
>
> - Power-off call chain is atomic now, like the restart chain.
>
> - kernel/reboot.c changes are split up into several logical patches.
>
> - Added r-b from Michał Mirosław to unmodified patches from v7.
>
> - Added acks that were missing in v7 by accident.

The v8 looks much better than the previous versions to me.

I actually don't really have any comments on it except for the minor
remark regarding patch [1/27] sent separately.

Please just send an update of that one patch and I will queue up the
series for 5.19.

However, I'm going to send a pull request with it in the second half
of the merge window, after the majority of the other changes in the
subsystems touched by it have been integrated.

> v7: - Rebased on a recent linux-next. Dropped the recently removed
>   NDS32 architecture. Only SH and x86 arches left un-acked.
>
> - Added acks from Thomas Bogendoerfer and Krzysztof Kozlowski
>   to the MIPS and memory/emif patches respectively.
>
> - Made couple minor cosmetic improvements to the new API.
>
> - A month ago I joined Collabora and continuing to work on this series
>   on the company's time, so changed my email address to collabora.com
>
> v6: - Rebased on a recent linux-next.
>
> - Made minor couple cosmetic changes.
>
> v5: - Dropped patches which cleaned up notifier/reboot headers, as was
>   requested by Rafael Wysocki.
>
> - Dropped WARN_ON() from the code, as was requested by Rafael Wysocki.
>   Replaced it with pr_err() appropriately.
>
> - Dropped *_notifier_has_unique_priority() functions and added
>   *_notifier_chain_register_unique_prio() instead, as was suggested
>   by Michał Mirosław and Rafael Wysocki.
>
> - Dropped export of blocking_notifier_call_chain_is_empty() symbol,
>   as was suggested by Rafael Wysocki.
>
> - Michał Mirosław suggested that will be better to split up patch
>   that adds the new API to ease reviewing, but Rafael Wysocki asked
>   not add more patches, so I kept it as a single patch.
>
> - Added temporary "weak" stub for pm_power_off() which fixes linkage
>   failure once symbol is removed from arch/* code. Previously I missed
>   this problem because was only compile-testing object files.
>
> v4: - Made a very minor improvement to doc comments, clarifying couple
>   default values.
>
> - Corrected list of emails recipient by adding Linus, Sebastian,
>   Philipp and more NDS people. Removed bouncing emails.
>
> - Added acks that were given to v3.
>
> v3: - Renamed power_handler to sys_off_handler as was suggested by
>