From: Sunil V L <sunilvl@ventanamicro.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
Ard Biesheuvel <ardb+git@google.com>,
linux-arm-kernel@lists.infradead.org,
Feng Tang <feng.tang@linux.alibaba.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
Bibo Mao <maobibo@loongson.cn>,
linux-rtc@vger.kernel.org, linux-efi@vger.kernel.org,
xen-devel@lists.xenproject.org, x86@kernel.org,
linux-riscv@lists.infradead.org, loongarch@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] Remove unused EFI runtime APIs
Date: Tue, 15 Jul 2025 20:28:42 +0530 [thread overview]
Message-ID: <aHZsohPoxLYML___@sunil-laptop> (raw)
In-Reply-To: <CAMj1kXEXpBF8hPaVMU0sDgNysYT66MDRmr3JHO4Lg1sJB_Yteg@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Sunil V L <sunilvl@ventanamicro.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
Ard Biesheuvel <ardb+git@google.com>,
linux-arm-kernel@lists.infradead.org,
Feng Tang <feng.tang@linux.alibaba.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
Bibo Mao <maobibo@loongson.cn>,
linux-rtc@vger.kernel.org, linux-efi@vger.kernel.org,
xen-devel@lists.xenproject.org, x86@kernel.org,
linux-riscv@lists.infradead.org, loongarch@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] Remove unused EFI runtime APIs
Date: Tue, 15 Jul 2025 20:28:42 +0530 [thread overview]
Message-ID: <aHZsohPoxLYML___@sunil-laptop> (raw)
In-Reply-To: <CAMj1kXEXpBF8hPaVMU0sDgNysYT66MDRmr3JHO4Lg1sJB_Yteg@mail.gmail.com>
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-07-15 16:27 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-14 6:08 [RFC PATCH 0/3] Remove unused EFI runtime APIs Ard Biesheuvel
2025-07-14 6:08 ` Ard Biesheuvel
2025-07-14 6:08 ` [RFC PATCH 1/3] efi-rtc: Remove wakeup functionality Ard Biesheuvel
2025-07-14 6:08 ` Ard Biesheuvel
2025-07-14 6:13 ` Demi Marie Obenour
2025-07-14 6:13 ` Demi Marie Obenour
2025-07-14 6:19 ` Ard Biesheuvel
2025-07-14 6:19 ` Ard Biesheuvel
2025-07-14 6:22 ` Demi Marie Obenour
2025-07-14 6:22 ` Demi Marie Obenour
2025-07-14 6:34 ` Ard Biesheuvel
2025-07-14 6:34 ` Ard Biesheuvel
2025-07-14 7:16 ` Feng Tang
2025-07-14 7:16 ` Feng Tang
2025-08-03 1:04 ` Alexandre Belloni
2025-08-03 1:04 ` Alexandre Belloni
2025-08-09 23:02 ` Ard Biesheuvel
2025-08-09 23:02 ` Ard Biesheuvel
2025-09-14 21:16 ` (subset) " Alexandre Belloni
2025-09-14 21:16 ` Alexandre Belloni
2025-07-14 6:08 ` [RFC PATCH 2/3] efi/test: Don't bother pseudo-testing unused EFI services Ard Biesheuvel
2025-07-14 6:08 ` Ard Biesheuvel
2025-07-14 6:08 ` [RFC PATCH 3/3] efi: Remove support for pointless, " Ard Biesheuvel
2025-07-14 6:08 ` Ard Biesheuvel
2025-07-17 0:49 ` Stefano Stabellini
2025-07-17 0:49 ` Stefano Stabellini
2025-07-14 8:10 ` [RFC PATCH 0/3] Remove unused EFI runtime APIs Heinrich Schuchardt
2025-07-14 8:10 ` Heinrich Schuchardt
2025-07-15 3:29 ` Ard Biesheuvel
2025-07-15 3:29 ` Ard Biesheuvel
2025-07-15 14:58 ` Sunil V L [this message]
2025-07-15 14:58 ` Sunil V L
2025-07-16 3:52 ` Ard Biesheuvel
2025-07-16 3:52 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aHZsohPoxLYML___@sunil-laptop \
--to=sunilvl@ventanamicro.com \
--cc=alexandre.belloni@bootlin.com \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=feng.tang@linux.alibaba.com \
--cc=heinrich.schuchardt@canonical.com \
--cc=jgross@suse.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rtc@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=maobibo@loongson.cn \
--cc=oleksandr_tyshchenko@epam.com \
--cc=sstabellini@kernel.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.