linux-kernel - Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9e663a52-691c-4387-85b7-73e7f51086de@collabora.com>
Date: Wed, 10 Dec 2025 01:13:47 +0300
From: Dmitry Osipenko <dmitry.osipenko@...labora.com>
To: Antheas Kapenekakis <lkml@...heas.dev>,
 "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Mario Limonciello <superm1@...nel.org>,
 Robert Beckett <bob.beckett@...labora.com>, linux-acpi@...r.kernel.org,
 kernel@...labora.com, linux-kernel@...r.kernel.org,
 Sebastian Reichel <sebastian.reichel@...labora.com>,
 Xaver Hugl <xaver.hugl@...il.com>, Richard Hughes <richard@...hsie.com>,
 William Jon McCann <mccann@....edu>, "Jaap A . Haitsma" <jaap@...tsma.org>,
 Benjamin Canou <bookeldor@...il.com>, Bastien Nocera <hadess@...ess.net>,
 systemd-devel@...ts.freedesktop.org,
 Lennart Poettering <lennart@...ttering.net>
Subject: Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs
 interface

...
>> So let me repeat for extra clarity.
>>
>> The only change related to the LPS0 "screen off" and "screen on"
>> notifications that would be tentatively acceptable to me ATM, would be
>> to modify the suspend-to-idle flow to do the "screen off" notification
>> earlier (possibly even at the start of it) and the corresponding
>> "screen on" notification later (possibly at the end of it), provided
>> that one can convincingly argue that this should not introduce
>> regressions.
>>
> 
> From what I recall that was my original plan.
> 
> Yeah, it is a fair way forward. @Dmitry how would you like to approach
> this? SInce you re-started the discussion. What is your timeline/KPIs
> for this.
> 
> I could personally try to whip up a small series after the merge
> window by rewriting what I have[1]. I have more experience now in
> drafting this kind of thing and that series added some cruft to the pm
> core with multiple additions to platform_s2idle_ops
> 
> There is a _small_ quantitative difference due to moving the calls.
> Specifically, the power light responds a tad slower when waking a
> device. For the legion go (non-s) devices, Lenovo added a dummy 5
> second timer to resuming the controllers because of some Windows bugs,
> and moving the calls causes the timer to start later. But that's the
> OEM intended behavior...
> 
> Antheas
> 
> [1] https://github.com/bazzite-org/patchwork/commits/pm-bleeding/modern-standby/

Am I understanding correctly that the plan is to have a 2-stage freezer
for suspend-to-idle + standby mode? Rafael, could you please confirm
that you're fine with this 2-stage freezer part of the proposal from
Antheas?

What you expect to be a proper way of implementing a 2-stage freezer?
Would it be a new executable capability, a new syscall or extension of
existing one, a new cgroup type? How would you mark processes that
should not be frozen on the first stage? Or it would be only the process
that writes to /sysfs/power?

Thanks everyone for the very detailed input. It is all very productive,
helps a lot with adjusting my understanding of the modern suspend features.

Agree that the usefulness of the visual aspect of the Display
notification is questionable. Previously I thought this mode involves
power-limiting. The Sleep notification might be much more interesting then.

I'm heading to vacation till Jan. Antheas, I will be happy to review and
test your code if you'll have time to type a working prototype.
Otherwise, will continue after the Holidays and likely will use your
patches for the base.

-- 
Best regards,
Dmitry