arch/x86/platform/efi/efi_64.c | 22 ---- drivers/firmware/efi/runtime-wrappers.c | 68 ------------ drivers/firmware/efi/test/efi_test.c | 108 +------------------- drivers/rtc/rtc-efi.c | 76 +------------- drivers/xen/efi.c | 56 ---------- include/linux/efi.h | 6 -- 6 files changed, 4 insertions(+), 332 deletions(-)
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 same applies to GetNextHighMonoCount(), which, if implemented, usually relies on SetVariable() under the hood *, which is often not supported at runtime by non-x86 platforms. But it has no known users either so let's drop support for it as well. This means we need to drop the slightly pointless tests for it too. * EDK2 based EFI implementations usually have a MTC variable carrying the monotonic counter variable, which is therefore not truly monotonic, given that SetVariable() will happily overwrite it. Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Cc: Feng Tang <feng.tang@linux.alibaba.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Cc: Bibo Mao <maobibo@loongson.cn> Cc: linux-rtc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: xen-devel@lists.xenproject.org Cc: x86@kernel.org Cc: linux-riscv@lists.infradead.org Cc: loongarch@lists.linux.dev Ard Biesheuvel (3): efi-rtc: Remove wakeup functionality efi/test: Don't bother pseudo-testing unused EFI services efi: Remove support for pointless, unused EFI services arch/x86/platform/efi/efi_64.c | 22 ---- drivers/firmware/efi/runtime-wrappers.c | 68 ------------ drivers/firmware/efi/test/efi_test.c | 108 +------------------- drivers/rtc/rtc-efi.c | 76 +------------- drivers/xen/efi.c | 56 ---------- include/linux/efi.h | 6 -- 6 files changed, 4 insertions(+), 332 deletions(-) -- 2.50.0.727.gbf7dc18ff4-goog
On 7/14/25 08:08, Ard Biesheuvel wrote: > 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? Best regards Heinrich > > The same applies to GetNextHighMonoCount(), which, if implemented, > usually relies on SetVariable() under the hood *, which is often not > supported at runtime by non-x86 platforms. But it has no known users > either so let's drop support for it as well. > > This means we need to drop the slightly pointless tests for it too. > > * EDK2 based EFI implementations usually have a MTC variable carrying > the monotonic counter variable, which is therefore not truly > monotonic, given that SetVariable() will happily overwrite it. > > Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> > Cc: Feng Tang <feng.tang@linux.alibaba.com> > Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> > Cc: Juergen Gross <jgross@suse.com> > Cc: Stefano Stabellini <sstabellini@kernel.org> > Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > Cc: Sunil V L <sunilvl@ventanamicro.com> > Cc: Bibo Mao <maobibo@loongson.cn> > Cc: linux-rtc@vger.kernel.org > Cc: linux-efi@vger.kernel.org > Cc: xen-devel@lists.xenproject.org > Cc: x86@kernel.org > Cc: linux-riscv@lists.infradead.org > Cc: loongarch@lists.linux.dev > > Ard Biesheuvel (3): > efi-rtc: Remove wakeup functionality > efi/test: Don't bother pseudo-testing unused EFI services > efi: Remove support for pointless, unused EFI services > > arch/x86/platform/efi/efi_64.c | 22 ---- > drivers/firmware/efi/runtime-wrappers.c | 68 ------------ > drivers/firmware/efi/test/efi_test.c | 108 +------------------- > drivers/rtc/rtc-efi.c | 76 +------------- > drivers/xen/efi.c | 56 ---------- > include/linux/efi.h | 6 -- > 6 files changed, 4 insertions(+), 332 deletions(-) >
On Mon, 14 Jul 2025 at 18:11, Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote: > > On 7/14/25 08:08, Ard Biesheuvel wrote: > > 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.
On Tue, Jul 15, 2025 at 01:29:15PM +1000, Ard Biesheuvel wrote: > On Mon, 14 Jul 2025 at 18:11, Heinrich Schuchardt > <heinrich.schuchardt@canonical.com> wrote: > > > > On 7/14/25 08:08, Ard Biesheuvel wrote: > > > 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 > 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, Sunil
On Wed, 16 Jul 2025 at 00:58, Sunil V L <sunilvl@ventanamicro.com> wrote: > > On Tue, Jul 15, 2025 at 01:29:15PM +1000, Ard Biesheuvel wrote: > > On Mon, 14 Jul 2025 at 18:11, Heinrich Schuchardt > > <heinrich.schuchardt@canonical.com> wrote: > > > > > > On 7/14/25 08:08, Ard Biesheuvel wrote: > > > > 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 > > > 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].
© 2016 - 2025 Red Hat, Inc.