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 6405EC4345F for ; Tue, 16 Apr 2024 10:16:19 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XmVD47qV7rWk2E8VtA9uZPAhYZaKP8ZsJ5R6HQbFiJw=; b=xgUg5exorZgUXY 07kLDR0hstLC0L70ve6aRcBSvodvesaMrI+2q14mlAfFOvv4HJ6NbKxYXr0G+jjwpcGdYUlN2hmFf 1z0KX/xO7FY7+UPyOMSsuziaUa4smu4SPj2UbzQUqu1PanZoveQlDDHyyVaiR161gVEabdRuxpCAN Utn0JY6ysX44PwklmDZwuMW3rHgD+HsGv07J9Rdfod2h6caongoO+htNjVeREiFOqYCO0ADy1JTi5 ZLs/dgE/i7LnDt16z6ip8gZy/QeVEYNgyCpzFbvZFuAb75bAZoJqS/gcnfmDd3waQ4ifrRRVXqVTj auGYch7OtqJLtyNBMjhw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rwfrB-0000000BkIw-2umv; Tue, 16 Apr 2024 10:16:05 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rwfr7-0000000BkI2-3kEp for linux-arm-kernel@lists.infradead.org; Tue, 16 Apr 2024 10:16:04 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 92329339; Tue, 16 Apr 2024 03:16:23 -0700 (PDT) Received: from pluto (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 96B173F64C; Tue, 16 Apr 2024 03:15:54 -0700 (PDT) Date: Tue, 16 Apr 2024 11:15:52 +0100 From: Cristian Marussi To: Peng Fan Cc: "Peng Fan (OSS)" , "sudeep.holla@arm.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] firmware: arm_scmi: power_control: support suspend command Message-ID: References: <20240415101141.1591112-1-peng.fan@oss.nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240416_031602_016651_3F4A46E7 X-CRM114-Status: GOOD ( 27.48 ) X-BeenThere: linux-arm-kernel@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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Apr 16, 2024 at 07:01:42AM +0000, Peng Fan wrote: > Hi Cristian, > Hi, > > Subject: Re: [PATCH] firmware: arm_scmi: power_control: support suspend > > command > > > > On Mon, Apr 15, 2024 at 06:11:41PM +0800, Peng Fan (OSS) wrote: > > > From: Peng Fan > > > > > > Support System suspend notification. Using a work struct to call > > > pm_suspend. There is no way to pass suspend level to pm_suspend, so > > > use MEM as of now. > > > > > > > Hi Peng, > > > > > Signed-off-by: Peng Fan > > > --- > > > .../firmware/arm_scmi/scmi_power_control.c | 20 ++++++++++++++++++- > > > 1 file changed, 19 insertions(+), 1 deletion(-) > > > > > > > This LGTM in general, the only obsservation here is that while on shutdown > > by issuing a orderly_reboot() we in fact ask PID_1 to start a shutdown from > > Would you please share why PID_1 is involved here? orderly_reboot is just > schedule a work. For the shutdown case, orderly_reboot related scheduled work ends up in a call to /sbin/reboot via usermodehelper kernel facilities, so that, depending on what PID_1 you have and how it is configured, PID_1 does have a chance to perform some additional task (if configured) before triggering the real final shutdown....this is done because the SCMI Notification is supposed to be a graceful request, so we dont just kernel_poweroff or similar. As an example with SystemD PID_1 /sbin/reboot is just a link to systemctl and you can place whatever you want in /usr/lib/systemd/system-shutdown/ and that it will executed by systemctl before kernel shutdown is really triggered. > > userspace, when triggering a system suspend with pm_suspend() we do not > > involve userspace in the process, but I dont think there is another way indeed. > > Userspace process should not be involved, otherwise the freezing process will > never finish, and suspend will abort. > Similarly in the suspend case when you initiate it from userspace (systemcl suspend) you can place something in /usr/lib/systemd/system-sleep/ and have it executed before suspend is passwed on to the kernel, BUT in our case we are not passing through userspace and it seems there is no way to do it, indeed, like we do for shutdown with orderly_reboot(). Moreover userspace, as Sudeep mentioned in the other thread, could be configured to trigger a different type of suspend, it it was involved at all in this process. But, as said, I dont think there is a way to trigger a userspace suspennd from jernel like we do for shutdown/reboot...I'll try to investigate a bit more. Anyway the change seems good to me as I said. Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel