From mboxrd@z Thu Jan 1 00:00:00 1970 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 6FB45C433F5 for ; Sun, 28 Nov 2021 21:06:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358719AbhK1VJd (ORCPT ); Sun, 28 Nov 2021 16:09:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358715AbhK1VHa (ORCPT ); Sun, 28 Nov 2021 16:07:30 -0500 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BFAF4C061763; Sun, 28 Nov 2021 13:04:13 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id u22so30582768lju.7; Sun, 28 Nov 2021 13:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wtn5Hkee5e4Yh99ylBrB3oNbIRTQMbXx6i2LcHRuAAA=; b=D7axuJW5K4soTW7ePg2XEY/iNxftObXK2r+AyGGcLpSZUVVVDeOdARXPvJKsrnTiWz AoAXcXPY5kZDAFmNd2VORgyu8fNJK2h3Akf7Z4wOIV4j7hl4k+Lg94oWKvPyZvxvLsrU gHjqykqz9pVTUOOpARf13AebW7syYSoupun9EMn0XvrUZckKr/LqJa+4eSWKEzDWJLdo K7OPzWs09+Av5yHcfZj3Q7MZQ+BDltCGiVFFVwhBt7T15YiSiT0WAJ3uiNnPq9pF4dyU I8pWXsXnC3XNCL+7zY4D1T6JR7EW9moTsiVuNSfEmpW1ojxHFbjsYoYQXbcJq5XV5+Um iPxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wtn5Hkee5e4Yh99ylBrB3oNbIRTQMbXx6i2LcHRuAAA=; b=vrIZVpDT3tnzcveZGsfsZ+sQpoSpPnctxxF5MXi6Ki48xD5/nIR3HxPBhqg9ZbfsCn 4ZevCQ6yGiBw0SuAoZbvGQAwtmQXJcm9ehhj1Xm8fkwAT89v4n6U3GxZZQh93rwEUZon sXsUxKnnTjb1iEA45kQH5/ObPXpXN4nv+oiJ2/oNYxkwqDJeGDbjzNRcw6h2zG1t3qi4 tcQul+/L9S82LkeDFeJbiGhN98c+Bh10RpBJ0Pqiu1LGtu6kWUwFbkyCdDbbkyRwSVwE PJbp7X0RwNtRCbA3qfSsppTgZJ04LOr9/P5GG5wEn//PG06Yl0HhUPhDayocwjEDRlPB XMqg== X-Gm-Message-State: AOAM533w/p62Q3K+3XACckNIHGvJlSknW5xp4/rx1IFpYmeM0rcYt3Bg LHouOxz4uJAURZYFCLWgys7ZLXmTFFA= X-Google-Smtp-Source: ABdhPJxH7knkFdz7TFpFlawyIdB41srtPJMqsrOfzCPJDLK6AlWk3m8N6okcECoeJRZyDtP9PR9VhQ== X-Received: by 2002:a05:651c:1257:: with SMTP id h23mr44458754ljh.17.1638133451873; Sun, 28 Nov 2021 13:04:11 -0800 (PST) Received: from [192.168.2.145] (94-29-46-111.dynamic.spd-mgts.ru. [94.29.46.111]) by smtp.googlemail.com with ESMTPSA id c17sm1100736lfr.235.2021.11.28.13.04.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Nov 2021 13:04:11 -0800 (PST) Subject: Re: [PATCH v4 08/25] kernel: Add combined power-off+restart handler call chain API To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= 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 References: <20211126180101.27818-1-digetx@gmail.com> <20211126180101.27818-9-digetx@gmail.com> From: Dmitry Osipenko Message-ID: <9213569e-0f40-0df1-4710-8dab564e12d6@gmail.com> Date: Mon, 29 Nov 2021 00:04:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 28.11.2021 03:43, Michał Mirosław пишет: > 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? Hello Michał, At minimum this makes code easier to follow. > 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'm having trouble with parsing this comment. Could you please try to rephrase it? I don't see how you could check whether power-off handler is available if you'll mix all handlers together. > I would also split this patch into preparation cleanups (like wrapping > pm_power_off call with a function) and adding the notifier-based > implementation. What's the benefit of this split up will be? Are you suggesting that it will ease reviewing of this patch or something else?