Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp296626pxb; Thu, 27 Jan 2022 22:23:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJwarSRLam4BITM7NXYfahcnxe9fFC6X6MR5WRhGfMLPePimV4amuwgUGgqw05u4y2p7uVgJ X-Received: by 2002:a05:6402:3552:: with SMTP id f18mr6796981edd.189.1643351017748; Thu, 27 Jan 2022 22:23:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643351017; cv=none; d=google.com; s=arc-20160816; b=Y3P1umYm1fxNiOHi6NoAevMexNIJz7LLQuC3j7eTlLVvCpNZam6z400TZbx/Qo060W O1b9f5yFwoh0hLD9e9j6U7esYZ+4WbYwqs4/yNGkGt7w2kC5ZQB793bUZSCWubd/QFyC SQXViMqQ3vjCFkeGy65CYEMsa09iL+lgdEhAKktYilhajMeK+VLAOhKnjstYr333Q7eg YYq4S3vwpxhd2wiZ1Nj38C7lHMt6gYOh9uNFCMiffryC8vTjoIYn5B0fPkL34f+UxfDC asipWyrUCDbYEEprXgdBJab9c2bE+MLi0E6cHEJl7QSxwzRsQ2VR6I7Rpn51IGzcAIJi yzIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=XkYKE/mqIw+ZogEPzGoXmtOQI8nkKTmA4V70TLbVWS4=; b=HYW03rmAoU3pTiC4ZdOZHzYL7gQqBSnzq3iFh9Zp1oKZjC+UJG4rQubwZzZ4whnyZ+ Vc2gJAMmRhcQwQSK0wlXL+Ry811jr4bSHgKxJvM6EWFBYRBd9Mmbi7tiHnicAYPd5TJE TiUB/r9DrTqHQnN2Z/Bfz+D1sPqLYZ82/egm9aSJl4L3UkqRHKlKh8MOzXH2XZdjUvrh WE9ChEwi6Fl9ijKCA7E0JoHGrSSyjcChAuw4jsVs9TMPdIjBafLqqZytHOwzUaRmxDg6 Un96kC1Nts9jN2oryQcoi39pcaLk0KRcGKM45AOY9RIU8b2QxKEG+8zUGiZFtJcMGvDy Ch9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=BHb2Xn1j; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ho42si3020819ejc.996.2022.01.27.22.23.13; Thu, 27 Jan 2022 22:23:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=BHb2Xn1j; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242522AbiA0Ojc (ORCPT + 99 others); Thu, 27 Jan 2022 09:39:32 -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-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-kernel@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.