On Wed, 16 Jul 2025 at 00:58, Sunil V L [off-list ref] wrote:

On Tue, Jul 15, 2025 at 01:29:15PM +1000, Ard Biesheuvel wrote:

quoted

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

quoted

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.

Hi Ard,
IIUC, TAD is defined for this purpose, right?
https://uefi.org/specs/ACPI/6.6/09_ACPI_Defined_Devices_and_Device_Specific_Objects.html#time-and-alarm-device

quoted

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.

I agree. But I think even with ACPI, EFI GetTime/SetTime can return
unsupported if there is a TAD exposed with proper _GRT/_SRT and _GCP.

Thanks for the pointer. This device did not exist yet when I last
looked at this stuff.

So it seems like TAD is a suitable way for exposing a RTC to the OS
without the need for a hardware specific driver. However, the existing
Linux driver does not appear to support get/set time, and is not
hooked up to the RTC subsystem [yet].