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: 
 <CAGwozwEQRcK13Ys9ER8YsLoWyYPDSLrdZjtC2KFYJ23DBC6K9w@mail.gmail.com>
Date: Tue, 9 Dec 2025 23:22:33 +0100
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Dmitry Osipenko <dmitry.osipenko@...labora.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
 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

On Tue, 9 Dec 2025 at 23:14, Dmitry Osipenko
<dmitry.osipenko@...labora.com> wrote:
>
> ...
> >> 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?

2 stages here refers to a two patch series, where the first part moves
the firmware notifications to the beginning of the suspend sequence
and the second part introduces a sysfs entry.

This way, it can be verified that it is ok for these calls to be
moved, and thereafter they are only called before the suspend
sequence, not both depending on userspace involvement.

In your series, you introduce a call from userspace, but then do the
fallback call at the end of the suspend sequence/beginning of resume.

> 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?

This would be handled by the init process without any kernel
extension, so it is a bit tangential.

You can reference the current freezer group in systemd-sleep for what
is done currently. It was introduced to prevent waking programs during
the transition to hibernation. In addition, freezing userspace _tends_
to improve VRAM evacuation when preparing for hibernation and cache
evacuation %, among other things.

So under systemd, the kernel essentially is only responsible for
freezing systemd.

> 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.

Happy holidays. I am also heading off soon, but I might have some time
in the meantime.


Best,
Antheas



> --
> Best regards,
> Dmitry
>