On Mon, 14 Jul 2025 at 18:11, Heinrich Schuchardt
[off-list ref] wrote:

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

quoted

From: Ard Biesheuvel <ardb@kernel.org>

Using EFI runtime services to program the RTC to wake up the system is
supported in theory, but rarely works in practice. Fortunately, this
functionality is rarely [if ever] used to begin with so we can just drop
it. (Note that the EFI rtc driver is not used by x86, which programs the
CMOS rtc directly)

The main problem I see with firmware offering access to the RTC via UEFI
services is that two different drivers, the firmware one and the Linux
one might be trying to access the same busses or registers which might
lead to unexpected results.

Recently there was a discussion in the RISC-V technical group for the
server platform specification where the same issue was discussed
concerning SetTime().

As a UEFI firmware should not care which operating system is booted, it
should be up to the OS to disable EFI access to the RTC if it has native
access.

Could we disable all the EFI services for the RTC in Linux dynamically
when an RTC driver is successfully probed?

I don't think this would be the right way to do it.

It also depends on whether ACPI or DT is being used to describe the
platform to the OS.

ACPI does not support describing the RTC device, so it should provide
the EFI services.

DT can describe the RTC device directly, so I think it is acceptable
for such firmware to mark all RTC routines unsupported in the RT_PROP
table, and just expose the RTC device directly.

The OS shouldn't have to reason about these things: it is up to the
platform to describe itself unambiguously.