Message-ID: <b98a8486-e90a-4bd5-b3a7-3b2ba1b16398@kernel.org>
Date: Tue, 28 Oct 2025 22:36:39 -0500
From: "Mario Limonciello (AMD) (kernel.org)" <superm1@...nel.org>
To: Antheas Kapenekakis <lkml@...heas.dev>
Cc: platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-hwmon@...r.kernel.org, Hans de Goede <hansg@...nel.org>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Derek John Clark <derekjohn.clark@...il.com>,
 Joaquín Ignacio Aramendía <samsagax@...il.com>,
 Jean Delvare <jdelvare@...e.com>, Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH v2 6/6] platform/x86: ayaneo-ec: Add suspend hook



On 10/28/2025 4:39 PM, Antheas Kapenekakis wrote:
> On Tue, 28 Oct 2025 at 22:21, Mario Limonciello <superm1@...nel.org> wrote:
>>
>> On 10/28/25 3:34 PM, Antheas Kapenekakis wrote:
>>>>> The fan speed is also lost during hibernation, but since hibernation
>>>>> failures are common with this class of devices
>> Why are hibernation failures more common in this class of device than
>> anything else?  The hibernation flow is nearly all done in Linux driver
>> code (with the exception of ACPI calls that move devices into D3 and out
>> of D0).
> 
> I should correct myself here and say hibernation in general in Linux
> leaves something to be desired.
> 
> Until secure boot supports hibernation, that will be the case because
> not enough people use it.

The upstream kernel has no tie between UEFI secure boot and hibernation. 
  I think you're talking about some distro kernels that tie UEFI secure 
boot to lockdown.  Lockdown does currently prohibit hibernation.

> 
> I have had it break for multiple reasons, not incl. the ones below and
> the ones we discussed last year where games are loaded.
> 
> For a few months I fixed some of the bugs but it is not sustainable.
> 
>> Perhaps you're seeing a manifestation of a general issue that we're
>> working on a solution for here:
>>
>> https://lore.kernel.org/linux-pm/20251025050812.421905-1-safinaskar@gmail.com/
>>
>> https://lore.kernel.org/linux-pm/20251026033115.436448-1-superm1@kernel.org/
>>
>> https://lore.kernel.org/linux-pm/5935682.DvuYhMxLoT@rafael.j.wysocki/T/#u
>>
>> Or if you're on an older kernel and using hybrid sleep we had a generic
>> issue there as well which was fixed in 6.18-rc1.
>>
>> Nonetheless; don't make policy decisions based upon kernel bugs.  Fix
>> the kernel bugs.
> 
> My problem is I cannot in good conscience restore a fan speed before
> the program responsible for it is guaranteed to thaw.
> 
> The best solution I can come up with would be in freeze save if manual
> control is enabled, disable it, and then on resume set a flag that
> makes the first write to fan speed also set pwm to manual.
> 
> This way suspend->hibernate flows, even if hibernation hangs when
> creating the image, at least have proper fan control because they are
> unattended, and resume hangs work similarly.
> 
> Antheas
> 

This sounds like a workable approach for what I understand to be your 
current design; but let me suggest some other ideas.

What happens if you're running something big and the OOM comes and 
whacks the process?  Now you don't have fan control running anymore.

So I see two options to improve things.

1) You can have userspace send a "heartbeat" to kernel space.  This can 
be as simple as a timestamp of reading a sysfs file.  If userspace 
doesn't read the file in X ms then you turn off manual control.

2) You move everything to a kthread.  Userspace can read some input 
options or maybe pick a few curve settings, but leave all the important 
logic in that kthread.

Powered by blists - more mailing lists