Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76F4BC433F5 for ; Sun, 28 Nov 2021 00:45:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356785AbhK1Ast (ORCPT ); Sat, 27 Nov 2021 19:48:49 -0500 Received: from rere.qmqm.pl ([91.227.64.183]:12892 "EHLO rere.qmqm.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356720AbhK1Aqq (ORCPT ); Sat, 27 Nov 2021 19:46:46 -0500 Received: from remote.user (localhost [127.0.0.1]) by rere.qmqm.pl (Postfix) with ESMTPSA id 4J1qTm1DhtzNL; Sun, 28 Nov 2021 01:43:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rere.qmqm.pl; s=1; t=1638060207; bh=ymi2rjesYlmYsrxY12X8vblXPJWiCK3o6T/SGnAjDZo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=C6SfBZOFpiANlfwmDvX4OuIMVOJSlYKPAQ7cePS7VCRqQvRDRXyoU4e1HDyFW5286 aMp77cXaWF2QuMJ//PO7Wx9adwPHxvzWlhsVptz1Bv8pKTYitnPzWsGYgxjQNrOvV7 Uk484prqIxJAORTEmmGB3fc8u4Kn87uEVHmrPcrNw+TikFuKmaRxmZpfI/D7x9DxOR HEK/DHm3KCkqlnpSbmB87Uzzanvh59D/q1WHxqRBbTNokUG7ZgWXQQKaJ+DCHFVboG CiQGnas3tcMmGH5URTeE0feIhbti0vtOii+M7lKOB+wnpM9RCc3cCyDZ3xGFva1jKa oHCSKPMXxlqVw== X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.3 at mail Date: Sun, 28 Nov 2021 01:43:22 +0100 From: =?iso-8859-2?Q?Micha=B3_Miros=B3aw?= To: Dmitry Osipenko Cc: Thierry Reding , Jonathan Hunter , Russell King , Catalin Marinas , Will Deacon , Guo Ren , Geert Uytterhoeven , Greg Ungerer , Joshua Thompson , Thomas Bogendoerfer , Sebastian Reichel , Linus Walleij , Philipp Zabel , Greentime Hu , Vincent Chen , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Paul Walmsley , Palmer Dabbelt , Albert Ou , Yoshinori Sato , Rich Felker , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Boris Ostrovsky , Juergen Gross , Stefano Stabellini , "Rafael J. Wysocki" , Len Brown , Santosh Shilimkar , Krzysztof Kozlowski , Liam Girdwood , Mark Brown , Pavel Machek , Lee Jones , Andrew Morton , Guenter Roeck , Daniel Lezcano , Andy Shevchenko , Ulf Hansson , alankao@andestech.com, "K . C . Kuen-Chern Lin" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-csky@vger.kernel.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org Subject: Re: [PATCH v4 08/25] kernel: Add combined power-off+restart handler call chain API Message-ID: References: <20211126180101.27818-1-digetx@gmail.com> <20211126180101.27818-9-digetx@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211126180101.27818-9-digetx@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 26, 2021 at 09:00:44PM +0300, Dmitry Osipenko wrote: > SoC platforms often have multiple ways of how to perform system's > power-off and restart operations. Meanwhile today's kernel is limited to > a single option. Add combined power-off+restart handler call chain API, > which is inspired by the restart API. The new API provides both power-off > and restart functionality. > > The old pm_power_off method will be kept around till all users are > converted to the new API. > > Current restart API will be replaced by the new unified API since > new API is its superset. The restart functionality of the sys-off handler > API is built upon the existing restart-notifier APIs. > > In order to ease conversion to the new API, convenient helpers are added > for the common use-cases. They will reduce amount of boilerplate code and > remove global variables. These helpers preserve old behaviour for cases > where only one power-off handler is expected, this is what all existing > drivers want, and thus, they could be easily converted to the new API. > Users of the new API should explicitly enable power-off chaining by > setting corresponding flag of the power_handler structure. [...] Hi, A general question: do we really need three distinct chains for this? Can't there be only one that chain of callbacks that get a stage (RESTART_PREPARE, RESTART, POWER_OFF_PREPARE, POWER_OFF) and can ignore them at will? Calling through POWER_OFF_PREPARE would also return whether that POWER_OFF is possible (for kernel_can_power_off()). I would also split this patch into preparation cleanups (like wrapping pm_power_off call with a function) and adding the notifier-based implementation. Best Regards Micha??Miros?aw