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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 7E711CAC591 for ; Wed, 10 Sep 2025 08:01:24 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6F3AE10E88D; Wed, 10 Sep 2025 08:01:23 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (1024-bit key; unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="SBS/Rsse"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3199210E14C; Mon, 8 Sep 2025 14:41:55 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6F21144099; Mon, 8 Sep 2025 14:41:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7F82C4CEF1; Mon, 8 Sep 2025 14:41:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1757342515; bh=QA8+1tr7brTem22zB+pPbb3Pb/1XaSIDYubStR1J+c0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SBS/RssesVLX/VJuLdbwuauXCp03O+vb5iBteVppwG8XWw5JLrnwqRGjbcD6uI3If MbUR4xwEEj0zSfxeWEY3sYsI+AkUMpVhLJGvsaMfS4Azp9JIR8CF5qsqTs5VAsS2nn 5d5wpyksQDJFegCKprTXVt6aH0twfYOCyCDr0oXc= Date: Mon, 8 Sep 2025 16:41:51 +0200 From: Greg Kroah-Hartman To: Mario Limonciello Cc: "Rafael J . Wysocki" , Danilo Krummrich , Bjorn Helgaas , Pavel Machek , Len Brown , Christian =?iso-8859-1?Q?K=F6nig?= , "James E . J . Bottomley" , "Martin K . Petersen" , Steven Rostedt , "open list:HIBERNATION (aka Software Suspend, aka swsusp)" , "open list:RADEON and AMDGPU DRM DRIVERS" , "open list:DRM DRIVERS" , "open list:PCI SUBSYSTEM" , "open list:SCSI SUBSYSTEM" , "open list:USB SUBSYSTEM" , "open list:TRACING" , AceLan Kao , Kai-Heng Feng , Mark Pearson , Merthan =?utf-8?Q?Karaka=C5=9F?= , Eric Naim Subject: Re: [PATCH v6 RESEND 00/11] Improvements to S5 power consumption Message-ID: <2025090839-desktop-ladder-c2f7@gregkh> References: <20250906143642.2590808-1-superm1@kernel.org> <2025090852-coma-tycoon-9f37@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailman-Approved-At: Wed, 10 Sep 2025 08:01:12 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Mon, Sep 08, 2025 at 07:39:07AM -0500, Mario Limonciello wrote: > > > On 9/8/25 4:19 AM, Greg Kroah-Hartman wrote: > > On Sat, Sep 06, 2025 at 09:36:31AM -0500, Mario Limonciello (AMD) wrote: > > > A variety of issues both in function and in power consumption have been > > > raised as a result of devices not being put into a low power state when > > > the system is powered off. > > > > > > There have been some localized changes[1] to PCI core to help these issues, > > > but they have had various downsides. > > > > > > This series instead tries to use the S4 flow when the system is being > > > powered off. This lines up the behavior with what other operating systems > > > do as well. If for some reason that fails or is not supported, run their > > > shutdown() callbacks. > > > > > > Cc: AceLan Kao > > > Cc: Kai-Heng Feng > > > Cc: Mark Pearson > > > Cc: Merthan Karakaş > > > Cc: Eric Naim > > > --- > > > v6 RESEND: > > > * Resent because Greg said he was ignoring it and would like the whole > > > series to be able to review. > > > > Messy, but wow, I'll trust you all that this actually works properly. > > Yes; I double checked from a UART log all devices (now) went to correct > state and from power measurement hardware the respective drop in power. > > I will note I have a sampling bias of hardware being x86 AMD hardware. > Some of the testers of the series also tested Intel hardware which had > similar power consumption problem, and I know there were improvements there > too. > > We probably will have to wait for linux-next for non-x86 hardware coverage. > > No objections from me, but I don't want my ack on this as I don't know > > how to maintain it :) > > > > I mean - if all goes well even a failed S4 flow should fall back to old path > shutdown. I *did contrive some failures* in an earlier version of the > series and confirmed in the UART log it emitted the printk that it was > falling back to shutdown. > > I had two ideas that maybe could help for regression risk though: > 1) I could add a shutdown= kernel parameter. I'm not sure what words to use > for the two paths but the idea would be if someone had a shutdown failure > they could isolate if it's due to this by adding the parameter. > > 2) I could make a Documentation/ file explaining some examples how to get > the shutdown log saved to pstore in case they don't have a UART available. This second one is probably the best. A new command line is not going to probably be used and just be a pain to maintain over time. thanks, greg k-h