From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 315F42FE598; Mon, 8 Sep 2025 12:39:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757335150; cv=none; b=EeIMP0RHw7FjrwCyR1JjzJNSR2VLM5XSJuaYm1cNT+Nz2ZBGpuWix0p7GYY5iu8nUL7JE1xcEXCoOR3qn0oekG9/FfBBJ0Cy+DW8wOQXQNs4y0DLoA9yqobQp2crb4BEtXci9tCThmYFkyELZ86y0lk393RJpbb8IZYb14XsOnA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757335150; c=relaxed/simple; bh=Kmgj7JQ2MfTOSMke4wzOHnSg8Sksyl64nAuAQ+DhI4A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=txoUPBc6zRjvFy/iM6Eum2PuclmrTR+x0oYJjk4+drzC6p7wmPIdyRwrT/GNSXLpwi22Lcp45nZqGL7cuMLWNZt921a6y6vwT/tUzNmeobHVWAFut0iuKYPKqdBZVQxHxeDKotN+skwaJmzPJrmqBYaH94e6LUHFzx21U6yvbK0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ufv6Hcx6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ufv6Hcx6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D710C4CEF1; Mon, 8 Sep 2025 12:39:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757335150; bh=Kmgj7JQ2MfTOSMke4wzOHnSg8Sksyl64nAuAQ+DhI4A=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Ufv6Hcx6jWD5AxW92cK+ljuNUfSXKHnQZv3kXveaEsZj/qc477qtV8lnGeC+yl2LV RS+Xs28IVJiEsEENic3DIoEPQdZSHhAU4cy+TktV0KVy4p51YIFXAv1grFur5A4cuH 6bQZcKwbFMBzc6sdl3QoFscqqxGb0GSshxGjTLYgZ5ZSGs+wSs4Anmp+mAqfz/3G43 d2i25P5YPiPUgIUQnhTbmOJCWuiJLaNYNMsOWex5ofVrrPe+JZ78aYrYUP0jSNG4sY WuOYdOOajtBz008C++gHVHO1nJV3AOOUYzXAxps+DjP5BGGjNMGuX5Ral+AlLsdZhH w1T2hkMKtFUDQ== Message-ID: Date: Mon, 8 Sep 2025 07:39:07 -0500 Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 RESEND 00/11] Improvements to S5 power consumption To: Greg Kroah-Hartman , "Rafael J . Wysocki" Cc: Danilo Krummrich , Bjorn Helgaas , Pavel Machek , Len Brown , =?UTF-8?Q?Christian_K=C3=B6nig?= , "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 , =?UTF-8?Q?Merthan_Karaka=C5=9F?= , Eric Naim References: <20250906143642.2590808-1-superm1@kernel.org> <2025090852-coma-tycoon-9f37@gregkh> Content-Language: en-US From: Mario Limonciello In-Reply-To: <2025090852-coma-tycoon-9f37@gregkh> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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.