On Mon, 14 Jul 2025 at 16:22, Demi Marie Obenour [off-list ref] wrote:

On 7/14/25 02:19, Ard Biesheuvel wrote:

quoted

On Mon, 14 Jul 2025 at 16:13, Demi Marie Obenour [off-list ref] wrote:

quoted

On 7/14/25 02:08, Ard Biesheuvel wrote:

quoted

From: Ard Biesheuvel <ardb@kernel.org>

The EFI rtc driver is used by non-x86 architectures only, and exposes
the get/set wakeup time functionality provided by the underlying
platform. This is usually broken on most platforms, and not widely used
to begin with [if at all], so let's just remove it.

systemd uses the underlying functionality: a timer can wake the system up.
I have no idea if that is implemented in terms of this function, though.

To be clear, you are referring to wake from poweroff at some date/time
in the future, right?

Yes.

quoted

This change does not remove this functionality from the RTC subsystem,
it just ceases to expose it on non-x86 EFI platforms that claim to
support it.

Do these platforms generally expose the functionality in a different way?

On x86, the CMOS rtc is manipulated directly (and this is officially
condoned by the EFI spec).

On non-x86, this functionality rarely works, which is really the point
of this series.

If not, systemd should probably document that the functionality is
non-portable if it doesn't do that already.

Not sure what you mean by non-portable. This functionality should be
exposed in a generic manner (using the RTC subsystem interfaces), but
only if it can be relied upon. On x86, the RTC subsystem will use the
rtc-cmos driver, which implements the wakeup routines in terms of port
I/O.

If removing this functionality altogether from the EFI rtc driver is a
problem, perhaps it would be better to implement an allowlist based
solution that does not attempt to access the runtime services by
default.