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 7B624C4332F for ; Thu, 27 Jan 2022 14:39:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237882AbiA0Ojb (ORCPT ); Thu, 27 Jan 2022 09:39:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242440AbiA0Oja (ORCPT ); Thu, 27 Jan 2022 09:39:30 -0500 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4ED3C061747; Thu, 27 Jan 2022 06:39:29 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id o12so5695802lfg.12; Thu, 27 Jan 2022 06:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=XkYKE/mqIw+ZogEPzGoXmtOQI8nkKTmA4V70TLbVWS4=; b=BHb2Xn1jq66/9MHahrzGm/gWUKtVbh/58wKW18vGWzni3fO5qyqP4VG1OOnOie8Jsh gDERoDSbSutwAXYx2C5vNn4TrrwM4BpgdHcNKbywEL+R5MYLhL5n2nGGvdHyYC3+WdiR AH7kOLTk/zgQKoF333ryAx/KFlOhDG6pX/tZk4LwhLgv5peCfB01DtWBVE+9RHO5Zn9/ GlTTQk4e9TGZCrINPfliTtlCZdTAH9LmWOb+qXQAmfLULPmn+Omh2L6j2NgulGAPM/A+ p0mPzTS/Ny1WZgGK/AicqnPTN5Ub7NU4t23e3Ka67Gnz7TG7Nyg0lXeqh7s3FoDGgrJx 11/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=XkYKE/mqIw+ZogEPzGoXmtOQI8nkKTmA4V70TLbVWS4=; b=6iLmI2H/+JAizdRH6u1BkFYrXGezfYRXBsQmrG1wzIbN24qW/yFCoQz0+XMdIv+q73 FuLJ5a4+50vMIMcbDUB/qV0D637F9LN1XErH7td7BBURsprUfxL/Vs8dvCyhUGCxqcCE X62D+ivGdSIulisip3vQj/PZLdqlCDRoPN3p5EG08/VUkKboGb4lMIovRmdkGOSgYqKt c4BJQuN+8rVdRv+010k6M0EL+wxXNxw4Gapg1Rz6P5RoGtHOXIzUkzrk7s/NM0TXJqQy rDgvK3mN8qGrqCpPe9PfIMPNpmjJmsKQy9qY+IyYOt72Anjm6/3xMzxyhS8tH8g5LYKz Y2Nw== X-Gm-Message-State: AOAM533hWHQ1QUAKT+lgDSES8w8zPc2JK3tXStRuzgstZIx7CvVncyGb cTyGmBUc2MqLgz77jeCl0k8= X-Google-Smtp-Source: ABdhPJy1MhVvMOXi8UxQ8s4idXCyJ+ifGIsp8CpwyHRf9+W1A9LbFInI9I0x2geweWfK/i1YhzfC+Q== X-Received: by 2002:a05:6512:3d1c:: with SMTP id d28mr2997039lfv.135.1643294367899; Thu, 27 Jan 2022 06:39:27 -0800 (PST) Received: from [192.168.2.145] (109-252-138-126.dynamic.spd-mgts.ru. [109.252.138.126]) by smtp.googlemail.com with ESMTPSA id r13sm476323lfr.65.2022.01.27.06.39.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jan 2022 06:39:22 -0800 (PST) Message-ID: Date: Thu, 27 Jan 2022 17:39:15 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v5 04/21] kernel: Add combined power-off+restart handler call chain API Content-Language: en-US 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-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: <20211212210309.9851-1-digetx@gmail.com> <20211212210309.9851-5-digetx@gmail.com> From: Dmitry Osipenko In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hello Michał, 09.01.2022 02:35, Michał Mirosław пишет: > BTW, I couldn't find a right description of my idea of unifying the > chains before, so let me sketch it now. > > The idea is to have a single system-off chain in which the callback > gets a mode ({QUERY_*, PREP_*, DO_*} for each of {*_REBOOT, *_POWEROFF, ...?). > The QUERY_* calls would be made in can_kernel_reboot/poweroff(): all > would be called, and if at least one returned true, then the shutdown > mode would continue. All of PREP_* would be called then. After that > all DO_* would be tried until one doesn't return (succeeded or broke > the system hard). Classic for(;;); could be a final fallback for the > case where arch/machine (lowest priority) call would return instead > of halting the system in machine-dependent way. The QUERY and PREP > stages could be combined, but I haven't thought about it enough to > see what conditions would need to be imposed on the callbacks in > that case (maybe it's not worth the trouble, since it isn't a fast > path anyway?). The goal here is to have less (duplicated) code in > kernel, but otherwise it seems equivalent to your API proposal. Thank you again for yours proposal! IMO, it's much more important to keep the core code simple and maintainable, rather than try to optimize it without a very good reason, given that this isn't a hot code path at all and saving a couple of bytes won't be noticeable. The poweroff, restart and reboot were separated before this series and I'm finding that it's easier to follow the code when it's structured that way. I'm not convinced that we need to change it. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Osipenko Date: Thu, 27 Jan 2022 14:39:15 +0000 Subject: Re: [PATCH v5 04/21] kernel: Add combined power-off+restart handler call chain API Message-Id: List-Id: References: <20211212210309.9851-1-digetx@gmail.com> <20211212210309.9851-5-digetx@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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-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 Hello Michał, 09.01.2022 02:35, Michał Mirosław пишет: > BTW, I couldn't find a right description of my idea of unifying the > chains before, so let me sketch it now. > > The idea is to have a single system-off chain in which the callback > gets a mode ({QUERY_*, PREP_*, DO_*} for each of {*_REBOOT, *_POWEROFF, ...?). > The QUERY_* calls would be made in can_kernel_reboot/poweroff(): all > would be called, and if at least one returned true, then the shutdown > mode would continue. All of PREP_* would be called then. After that > all DO_* would be tried until one doesn't return (succeeded or broke > the system hard). Classic for(;;); could be a final fallback for the > case where arch/machine (lowest priority) call would return instead > of halting the system in machine-dependent way. The QUERY and PREP > stages could be combined, but I haven't thought about it enough to > see what conditions would need to be imposed on the callbacks in > that case (maybe it's not worth the trouble, since it isn't a fast > path anyway?). The goal here is to have less (duplicated) code in > kernel, but otherwise it seems equivalent to your API proposal. Thank you again for yours proposal! IMO, it's much more important to keep the core code simple and maintainable, rather than try to optimize it without a very good reason, given that this isn't a hot code path at all and saving a couple of bytes won't be noticeable. The poweroff, restart and reboot were separated before this series and I'm finding that it's easier to follow the code when it's structured that way. I'm not convinced that we need to change it. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 03FDEC433EF for ; Thu, 27 Jan 2022 14:39:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WG807zdnNEHKLLiUmTK3sgjXIHJ2ShyZyyz+K6BLVdI=; b=dbXgVSjVWJEmBl 5z3zGw6tO4buP2WD0dbu0qLqRwxXZzaoGiMoIpVBm88cTIkPtFrwRwmmUj3PbANFw5uWM7FaXg5rp O4lRZnPJhHwJBF7JjR428MwcypjQsE1/KYB6l16PfwkIx/uGuKVYAjNc5LhLJOPfoEDYqTIkHVrBk /a4X3vSh2Wu+10dgezQMpIXQxe0Q4RCcCgxfW9pGXTbAVzs93EiRZFS/aoHHNUXvJAGeARYPEhhJV G6p3IDu2uKteg7/wv6et3Pets4jj86xkRSeLiLcVaqHoPOPvXNAW8QEW7giJkj0baa79E90vIGRcy 3MKDW8rfUOPNRGg9kmsA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nD5vy-00G69D-Sx; Thu, 27 Jan 2022 14:39:34 +0000 Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nD5vu-00G67X-U8 for linux-riscv@lists.infradead.org; Thu, 27 Jan 2022 14:39:33 +0000 Received: by mail-lf1-x134.google.com with SMTP id u14so5718266lfo.11 for ; Thu, 27 Jan 2022 06:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=XkYKE/mqIw+ZogEPzGoXmtOQI8nkKTmA4V70TLbVWS4=; b=BHb2Xn1jq66/9MHahrzGm/gWUKtVbh/58wKW18vGWzni3fO5qyqP4VG1OOnOie8Jsh gDERoDSbSutwAXYx2C5vNn4TrrwM4BpgdHcNKbywEL+R5MYLhL5n2nGGvdHyYC3+WdiR AH7kOLTk/zgQKoF333ryAx/KFlOhDG6pX/tZk4LwhLgv5peCfB01DtWBVE+9RHO5Zn9/ GlTTQk4e9TGZCrINPfliTtlCZdTAH9LmWOb+qXQAmfLULPmn+Omh2L6j2NgulGAPM/A+ p0mPzTS/Ny1WZgGK/AicqnPTN5Ub7NU4t23e3Ka67Gnz7TG7Nyg0lXeqh7s3FoDGgrJx 11/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=XkYKE/mqIw+ZogEPzGoXmtOQI8nkKTmA4V70TLbVWS4=; b=dKreWKg0EGvkHpkdhM6UUBxv2OaWJIzynPYqv7Ah5DS/4Ld1KkMCUEcMb5MOWi+cFa Pub8A6z1GlPdyzbWk63em7lPJo7Twik/c0wZubIgvNyl5n0XCggQgo9bD4+eI4mxsujW Kq5vu+l+brUxqaxuvw/cqSvCaD5lldVnZJBfSz/v6s+24iVLnGcLvesnWHD4ZbeoF3Dv PhTBiFKHVQ9YuSQvxZ0M6N0I3ZxcIjqhH+IHqvE+tet54qHjojCta8o/agoLxp7EBU8/ ux1k2vxe4bU4XhmHi2WCZ64m4ly4FATd0Gn/fhVlxUFlQoUC9s+mMIm55qk0ZiaSU4LB VKrw== X-Gm-Message-State: AOAM533XKpLREPnbqV0QikqPcQ6IUcXtcP5RSq5uDpReacQMujLk454t j9ov2k9E70BPqbGE/L5OvHs= X-Google-Smtp-Source: ABdhPJy1MhVvMOXi8UxQ8s4idXCyJ+ifGIsp8CpwyHRf9+W1A9LbFInI9I0x2geweWfK/i1YhzfC+Q== X-Received: by 2002:a05:6512:3d1c:: with SMTP id d28mr2997039lfv.135.1643294367899; Thu, 27 Jan 2022 06:39:27 -0800 (PST) Received: from [192.168.2.145] (109-252-138-126.dynamic.spd-mgts.ru. [109.252.138.126]) by smtp.googlemail.com with ESMTPSA id r13sm476323lfr.65.2022.01.27.06.39.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jan 2022 06:39:22 -0800 (PST) Message-ID: Date: Thu, 27 Jan 2022 17:39:15 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v5 04/21] kernel: Add combined power-off+restart handler call chain API Content-Language: en-US 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-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: <20211212210309.9851-1-digetx@gmail.com> <20211212210309.9851-5-digetx@gmail.com> From: Dmitry Osipenko In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220127_063930_994265_00659C8E X-CRM114-Status: GOOD ( 22.46 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org SGVsbG8gTWljaGHFgiwKCjA5LjAxLjIwMjIgMDI6MzUsIE1pY2hhxYIgTWlyb3PFgmF3INC/0LjR iNC10YI6Cj4gQlRXLCBJIGNvdWxkbid0IGZpbmQgYSByaWdodCBkZXNjcmlwdGlvbiBvZiBteSBp ZGVhIG9mIHVuaWZ5aW5nIHRoZQo+IGNoYWlucyBiZWZvcmUsIHNvIGxldCBtZSBza2V0Y2ggaXQg bm93Lgo+IAo+IFRoZSBpZGVhIGlzIHRvIGhhdmUgYSBzaW5nbGUgc3lzdGVtLW9mZiBjaGFpbiBp biB3aGljaCB0aGUgY2FsbGJhY2sKPiBnZXRzIGEgbW9kZSAoe1FVRVJZXyosIFBSRVBfKiwgRE9f Kn0gZm9yIGVhY2ggb2YgeypfUkVCT09ULCAqX1BPV0VST0ZGLCAuLi4/KS4KPiBUaGUgUVVFUllf KiBjYWxscyB3b3VsZCBiZSBtYWRlIGluIGNhbl9rZXJuZWxfcmVib290L3Bvd2Vyb2ZmKCk6IGFs bAo+IHdvdWxkIGJlIGNhbGxlZCwgYW5kIGlmIGF0IGxlYXN0IG9uZSByZXR1cm5lZCB0cnVlLCB0 aGVuIHRoZSBzaHV0ZG93bgo+IG1vZGUgd291bGQgY29udGludWUuIEFsbCBvZiBQUkVQXyogd291 bGQgYmUgY2FsbGVkIHRoZW4uIEFmdGVyIHRoYXQKPiBhbGwgRE9fKiB3b3VsZCBiZSB0cmllZCB1 bnRpbCBvbmUgZG9lc24ndCByZXR1cm4gKHN1Y2NlZWRlZCBvciBicm9rZQo+IHRoZSBzeXN0ZW0g aGFyZCkuIENsYXNzaWMgZm9yKDs7KTsgY291bGQgYmUgYSBmaW5hbCBmYWxsYmFjayBmb3IgdGhl Cj4gY2FzZSB3aGVyZSBhcmNoL21hY2hpbmUgKGxvd2VzdCBwcmlvcml0eSkgY2FsbCB3b3VsZCBy ZXR1cm4gaW5zdGVhZAo+IG9mIGhhbHRpbmcgdGhlIHN5c3RlbSBpbiBtYWNoaW5lLWRlcGVuZGVu dCB3YXkuIFRoZSBRVUVSWSBhbmQgUFJFUAo+IHN0YWdlcyBjb3VsZCBiZSBjb21iaW5lZCwgYnV0 IEkgaGF2ZW4ndCB0aG91Z2h0IGFib3V0IGl0IGVub3VnaCB0bwo+IHNlZSB3aGF0IGNvbmRpdGlv bnMgd291bGQgbmVlZCB0byBiZSBpbXBvc2VkIG9uIHRoZSBjYWxsYmFja3MgaW4KPiB0aGF0IGNh c2UgKG1heWJlIGl0J3Mgbm90IHdvcnRoIHRoZSB0cm91YmxlLCBzaW5jZSBpdCBpc24ndCBhIGZh c3QKPiBwYXRoIGFueXdheT8pLiBUaGUgZ29hbCBoZXJlIGlzIHRvIGhhdmUgbGVzcyAoZHVwbGlj YXRlZCkgY29kZSBpbgo+IGtlcm5lbCwgYnV0IG90aGVyd2lzZSBpdCBzZWVtcyBlcXVpdmFsZW50 IHRvIHlvdXIgQVBJIHByb3Bvc2FsLgoKVGhhbmsgeW91IGFnYWluIGZvciB5b3VycyBwcm9wb3Nh bCEgSU1PLCBpdCdzIG11Y2ggbW9yZSBpbXBvcnRhbnQgdG8Ka2VlcCB0aGUgY29yZSBjb2RlIHNp bXBsZSBhbmQgbWFpbnRhaW5hYmxlLCByYXRoZXIgdGhhbiB0cnkgdG8gb3B0aW1pemUKaXQgd2l0 aG91dCBhIHZlcnkgZ29vZCByZWFzb24sIGdpdmVuIHRoYXQgdGhpcyBpc24ndCBhIGhvdCBjb2Rl IHBhdGggYXQKYWxsIGFuZCBzYXZpbmcgYSBjb3VwbGUgb2YgYnl0ZXMgd29uJ3QgYmUgbm90aWNl YWJsZS4gVGhlIHBvd2Vyb2ZmLApyZXN0YXJ0IGFuZCByZWJvb3Qgd2VyZSBzZXBhcmF0ZWQgYmVm b3JlIHRoaXMgc2VyaWVzIGFuZCBJJ20gZmluZGluZwp0aGF0IGl0J3MgZWFzaWVyIHRvIGZvbGxv dyB0aGUgY29kZSB3aGVuIGl0J3Mgc3RydWN0dXJlZCB0aGF0IHdheS4gSSdtCm5vdCBjb252aW5j ZWQgdGhhdCB3ZSBuZWVkIHRvIGNoYW5nZSBpdC4KCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCmxpbnV4LXJpc2N2IG1haWxpbmcgbGlzdApsaW51eC1yaXNj dkBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4v bGlzdGluZm8vbGludXgtcmlzY3YK 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7015DC433EF for ; Thu, 27 Jan 2022 21:46:29 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4JlDgR55N8z3bbR for ; Fri, 28 Jan 2022 08:46:27 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=BHb2Xn1j; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2a00:1450:4864:20::129; helo=mail-lf1-x129.google.com; envelope-from=digetx@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=BHb2Xn1j; dkim-atps=neutral Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Jl3Bz6Blzz3bNs for ; Fri, 28 Jan 2022 01:39:37 +1100 (AEDT) Received: by mail-lf1-x129.google.com with SMTP id bu18so5762746lfb.5 for ; Thu, 27 Jan 2022 06:39:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=XkYKE/mqIw+ZogEPzGoXmtOQI8nkKTmA4V70TLbVWS4=; b=BHb2Xn1jq66/9MHahrzGm/gWUKtVbh/58wKW18vGWzni3fO5qyqP4VG1OOnOie8Jsh gDERoDSbSutwAXYx2C5vNn4TrrwM4BpgdHcNKbywEL+R5MYLhL5n2nGGvdHyYC3+WdiR AH7kOLTk/zgQKoF333ryAx/KFlOhDG6pX/tZk4LwhLgv5peCfB01DtWBVE+9RHO5Zn9/ GlTTQk4e9TGZCrINPfliTtlCZdTAH9LmWOb+qXQAmfLULPmn+Omh2L6j2NgulGAPM/A+ p0mPzTS/Ny1WZgGK/AicqnPTN5Ub7NU4t23e3Ka67Gnz7TG7Nyg0lXeqh7s3FoDGgrJx 11/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=XkYKE/mqIw+ZogEPzGoXmtOQI8nkKTmA4V70TLbVWS4=; b=SBu57AHO3ughvXD4vpXY+GpY9T/O8b1S7ibAvBb8lR1Wnx8ylhk1ESu3lI9+SmWkMp HPkxbL2WfKKSV2EttLjGgrbh3noBAhnQrVtMG7F5Hvo4Yh5iAbXYRBvj6eWwZ0Aa7Iql AuQ+L1BpPxiBjjursMzrH4GFuPIjaE3sNZXk/VIEQVEPwcVLIk0oKfvshJvv6dCpu+7Z R4+bJ8qA1XM8dwWOynJoXYHdiBLgki1RILLdi7xWSicD09uQjlyydpdYdUUxay/BtY5A +lv1az6L4eisN2BflMogCqL93wyE/7JdUoTDoUysSAbAfBHmTGDkw8MAXpHf4bXIqU92 42UA== X-Gm-Message-State: AOAM53140uor7IMcsCvRp6EvzWdYQBAC2NBntPcY9NQmKL9I3ot3QlSr fX/THedx6gA82H0x+hVV7I8= X-Google-Smtp-Source: ABdhPJy1MhVvMOXi8UxQ8s4idXCyJ+ifGIsp8CpwyHRf9+W1A9LbFInI9I0x2geweWfK/i1YhzfC+Q== X-Received: by 2002:a05:6512:3d1c:: with SMTP id d28mr2997039lfv.135.1643294367899; Thu, 27 Jan 2022 06:39:27 -0800 (PST) Received: from [192.168.2.145] (109-252-138-126.dynamic.spd-mgts.ru. [109.252.138.126]) by smtp.googlemail.com with ESMTPSA id r13sm476323lfr.65.2022.01.27.06.39.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jan 2022 06:39:22 -0800 (PST) Message-ID: Date: Thu, 27 Jan 2022 17:39:15 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v5 04/21] kernel: Add combined power-off+restart handler call chain API Content-Language: en-US To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= References: <20211212210309.9851-1-digetx@gmail.com> <20211212210309.9851-5-digetx@gmail.com> From: Dmitry Osipenko In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 28 Jan 2022 08:44:30 +1100 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ulf Hansson , Rich Felker , linux-ia64@vger.kernel.org, Santosh Shilimkar , "Rafael J. Wysocki" , Boris Ostrovsky , Linus Walleij , Dave Hansen , Liam Girdwood , "James E.J. Bottomley" , Thierry Reding , Paul Mackerras , Pavel Machek , "H. Peter Anvin" , linux-riscv@lists.infradead.org, Vincent Chen , Will Deacon , Greg Ungerer , Stefano Stabellini , alankao@andestech.com, Yoshinori Sato , Krzysztof Kozlowski , linux-sh@vger.kernel.org, Helge Deller , x86@kernel.org, Russell King , linux-csky@vger.kernel.org, Jonathan Hunter , linux-acpi@vger.kernel.org, Ingo Molnar , Geert Uytterhoeven , Catalin Marinas , xen-devel@lists.xenproject.org, linux-mips@vger.kernel.org, Guenter Roeck , Len Brown , Albert Ou , Lee Jones , linux-m68k@lists.linux-m68k.org, Mark Brown , Borislav Petkov , Greentime Hu , Paul Walmsley , linux-tegra@vger.kernel.org, Thomas Gleixner , Andy Shevchenko , Juergen Gross , Thomas Bogendoerfer , Daniel Lezcano , linux-parisc@vger.kernel.org, linux-pm@vger.kernel.org, Sebastian Reichel , linux-kernel@vger.kernel.org, "K . C . Kuen-Chern Lin" , Palmer Dabbelt , Philipp Zabel , Guo Ren , Andrew Morton , linuxppc-dev@lists.ozlabs.org, Joshua Thompson Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hello Michał, 09.01.2022 02:35, Michał Mirosław пишет: > BTW, I couldn't find a right description of my idea of unifying the > chains before, so let me sketch it now. > > The idea is to have a single system-off chain in which the callback > gets a mode ({QUERY_*, PREP_*, DO_*} for each of {*_REBOOT, *_POWEROFF, ...?). > The QUERY_* calls would be made in can_kernel_reboot/poweroff(): all > would be called, and if at least one returned true, then the shutdown > mode would continue. All of PREP_* would be called then. After that > all DO_* would be tried until one doesn't return (succeeded or broke > the system hard). Classic for(;;); could be a final fallback for the > case where arch/machine (lowest priority) call would return instead > of halting the system in machine-dependent way. The QUERY and PREP > stages could be combined, but I haven't thought about it enough to > see what conditions would need to be imposed on the callbacks in > that case (maybe it's not worth the trouble, since it isn't a fast > path anyway?). The goal here is to have less (duplicated) code in > kernel, but otherwise it seems equivalent to your API proposal. Thank you again for yours proposal! IMO, it's much more important to keep the core code simple and maintainable, rather than try to optimize it without a very good reason, given that this isn't a hot code path at all and saving a couple of bytes won't be noticeable. The poweroff, restart and reboot were separated before this series and I'm finding that it's easier to follow the code when it's structured that way. I'm not convinced that we need to change it.