drivers/rtc/rtc-efi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
The kernel selftest of rtc reported a error on an ARM server which
use rtc-efi device:
RUN rtc.alarm_alm_set ...
rtctest.c:262:alarm_alm_set:Alarm time now set to 17:31:36.
rtctest.c:267:alarm_alm_set:Expected -1 (-1) != rc (-1)
alarm_alm_set: Test terminated by assertion
FAIL rtc.alarm_alm_set
not ok 5 rtc.alarm_alm_set
The root cause is, the underlying EFI firmware doesn't support wakeup
service (get/set alarm), while it doesn't have the EFI RT_PROP table
either. As Ard Biesheuvel clarified [1], this breaks the UEFI spec,
which requires EFI firmware to provide a 'RT_PROP' table if it doesn't
support all runtime services (Section 4.6.2, UEFI spec 2.10).
This issue was also reproduced on ARM server from another vendor, which
doesn't have RT_PROP table either. This means, in real world, there are
quite some platforms having this issue, that it doesn't support wakeup
service while not providing a correct RT_PROP table, which makes it
wrongly claimed to support it.
Add a runtime check for the wakeup service to detect and correct this
kind of cases.
[1]. https://lore.kernel.org/lkml/CAMj1kXEkzXsjm0dPhzxB+KdtzqADd4NmafKmw2rKw7mAPBrgdA@mail.gmail.com/
Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com>
---
drivers/rtc/rtc-efi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index fa8bf82df948..8d1b9bde6f66 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -259,6 +259,7 @@ static int __init efi_rtc_probe(struct platform_device *dev)
struct rtc_device *rtc;
efi_time_t eft;
efi_time_cap_t cap;
+ efi_bool_t enabled, pending;
/* First check if the RTC is usable */
if (efi.get_time(&eft, &cap) != EFI_SUCCESS)
@@ -272,7 +273,8 @@ static int __init efi_rtc_probe(struct platform_device *dev)
rtc->ops = &efi_rtc_ops;
clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->features);
- if (efi_rt_services_supported(EFI_RT_SUPPORTED_WAKEUP_SERVICES))
+ if (efi_rt_services_supported(EFI_RT_SUPPORTED_WAKEUP_SERVICES) &&
+ efi.get_wakeup_time(&enabled, &pending, &eft) == EFI_SUCCESS)
set_bit(RTC_FEATURE_ALARM_WAKEUP_ONLY, rtc->features);
else
clear_bit(RTC_FEATURE_ALARM, rtc->features);
--
2.39.5 (Apple Git-154)On Thu, 10 Jul 2025 at 18:41, Feng Tang <feng.tang@linux.alibaba.com> wrote: > > The kernel selftest of rtc reported a error on an ARM server which > use rtc-efi device: > > RUN rtc.alarm_alm_set ... > rtctest.c:262:alarm_alm_set:Alarm time now set to 17:31:36. > rtctest.c:267:alarm_alm_set:Expected -1 (-1) != rc (-1) > alarm_alm_set: Test terminated by assertion > FAIL rtc.alarm_alm_set > not ok 5 rtc.alarm_alm_set > > The root cause is, the underlying EFI firmware doesn't support wakeup > service (get/set alarm), while it doesn't have the EFI RT_PROP table > either. As Ard Biesheuvel clarified [1], this breaks the UEFI spec, > which requires EFI firmware to provide a 'RT_PROP' table if it doesn't > support all runtime services (Section 4.6.2, UEFI spec 2.10). > > This issue was also reproduced on ARM server from another vendor, which > doesn't have RT_PROP table either. This means, in real world, there are > quite some platforms having this issue, that it doesn't support wakeup > service while not providing a correct RT_PROP table, which makes it > wrongly claimed to support it. > > Add a runtime check for the wakeup service to detect and correct this > kind of cases. > > [1]. https://lore.kernel.org/lkml/CAMj1kXEkzXsjm0dPhzxB+KdtzqADd4NmafKmw2rKw7mAPBrgdA@mail.gmail.com/ > > Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com> > --- > drivers/rtc/rtc-efi.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Thanks, I've queued this up now. > diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c > index fa8bf82df948..8d1b9bde6f66 100644 > --- a/drivers/rtc/rtc-efi.c > +++ b/drivers/rtc/rtc-efi.c > @@ -259,6 +259,7 @@ static int __init efi_rtc_probe(struct platform_device *dev) > struct rtc_device *rtc; > efi_time_t eft; > efi_time_cap_t cap; > + efi_bool_t enabled, pending; > > /* First check if the RTC is usable */ > if (efi.get_time(&eft, &cap) != EFI_SUCCESS) > @@ -272,7 +273,8 @@ static int __init efi_rtc_probe(struct platform_device *dev) > > rtc->ops = &efi_rtc_ops; > clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->features); > - if (efi_rt_services_supported(EFI_RT_SUPPORTED_WAKEUP_SERVICES)) > + if (efi_rt_services_supported(EFI_RT_SUPPORTED_WAKEUP_SERVICES) && > + efi.get_wakeup_time(&enabled, &pending, &eft) == EFI_SUCCESS) > set_bit(RTC_FEATURE_ALARM_WAKEUP_ONLY, rtc->features); > else > clear_bit(RTC_FEATURE_ALARM, rtc->features); > -- > 2.39.5 (Apple Git-154) > >
On Fri, 11 Jul 2025 at 11:06, Ard Biesheuvel <ardb@kernel.org> wrote: > > On Thu, 10 Jul 2025 at 18:41, Feng Tang <feng.tang@linux.alibaba.com> wrote: > > > > The kernel selftest of rtc reported a error on an ARM server which > > use rtc-efi device: > > > > RUN rtc.alarm_alm_set ... > > rtctest.c:262:alarm_alm_set:Alarm time now set to 17:31:36. > > rtctest.c:267:alarm_alm_set:Expected -1 (-1) != rc (-1) > > alarm_alm_set: Test terminated by assertion > > FAIL rtc.alarm_alm_set > > not ok 5 rtc.alarm_alm_set > > > > The root cause is, the underlying EFI firmware doesn't support wakeup > > service (get/set alarm), while it doesn't have the EFI RT_PROP table > > either. As Ard Biesheuvel clarified [1], this breaks the UEFI spec, > > which requires EFI firmware to provide a 'RT_PROP' table if it doesn't > > support all runtime services (Section 4.6.2, UEFI spec 2.10). > > > > This issue was also reproduced on ARM server from another vendor, which > > doesn't have RT_PROP table either. This means, in real world, there are > > quite some platforms having this issue, that it doesn't support wakeup > > service while not providing a correct RT_PROP table, which makes it > > wrongly claimed to support it. > > > > Add a runtime check for the wakeup service to detect and correct this > > kind of cases. > > > > [1]. https://lore.kernel.org/lkml/CAMj1kXEkzXsjm0dPhzxB+KdtzqADd4NmafKmw2rKw7mAPBrgdA@mail.gmail.com/ > > > > Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com> > > --- > > drivers/rtc/rtc-efi.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > Thanks, I've queued this up now. > Actually, we might just remove the EFI get/set wakeup time functionality altogether, as it seems rather pointless to me to begin with. I'll send out an RFC shortly.
On 11/07/2025 11:26:18+1000, Ard Biesheuvel wrote: > On Fri, 11 Jul 2025 at 11:06, Ard Biesheuvel <ardb@kernel.org> wrote: > > > > On Thu, 10 Jul 2025 at 18:41, Feng Tang <feng.tang@linux.alibaba.com> wrote: > > > > > > The kernel selftest of rtc reported a error on an ARM server which > > > use rtc-efi device: > > > > > > RUN rtc.alarm_alm_set ... > > > rtctest.c:262:alarm_alm_set:Alarm time now set to 17:31:36. > > > rtctest.c:267:alarm_alm_set:Expected -1 (-1) != rc (-1) > > > alarm_alm_set: Test terminated by assertion > > > FAIL rtc.alarm_alm_set > > > not ok 5 rtc.alarm_alm_set > > > > > > The root cause is, the underlying EFI firmware doesn't support wakeup > > > service (get/set alarm), while it doesn't have the EFI RT_PROP table > > > either. As Ard Biesheuvel clarified [1], this breaks the UEFI spec, > > > which requires EFI firmware to provide a 'RT_PROP' table if it doesn't > > > support all runtime services (Section 4.6.2, UEFI spec 2.10). > > > > > > This issue was also reproduced on ARM server from another vendor, which > > > doesn't have RT_PROP table either. This means, in real world, there are > > > quite some platforms having this issue, that it doesn't support wakeup > > > service while not providing a correct RT_PROP table, which makes it > > > wrongly claimed to support it. > > > > > > Add a runtime check for the wakeup service to detect and correct this > > > kind of cases. > > > > > > [1]. https://lore.kernel.org/lkml/CAMj1kXEkzXsjm0dPhzxB+KdtzqADd4NmafKmw2rKw7mAPBrgdA@mail.gmail.com/ > > > > > > Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com> > > > --- > > > drivers/rtc/rtc-efi.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > Thanks, I've queued this up now. > > > > Actually, we might just remove the EFI get/set wakeup time > functionality altogether, as it seems rather pointless to me to begin > with. > > I'll send out an RFC shortly. I guess this is going to also solve the issue reported by loongson https://lore.kernel.org/linux-rtc/20250613061747.4117470-1-wangming01@loongson.cn/ However, please let me take care of patches in my subsystem... -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Fri, 11 Jul 2025 at 18:56, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > On 11/07/2025 11:26:18+1000, Ard Biesheuvel wrote: > > On Fri, 11 Jul 2025 at 11:06, Ard Biesheuvel <ardb@kernel.org> wrote: > > > > > > On Thu, 10 Jul 2025 at 18:41, Feng Tang <feng.tang@linux.alibaba.com> wrote: > > > > > > > > The kernel selftest of rtc reported a error on an ARM server which > > > > use rtc-efi device: > > > > > > > > RUN rtc.alarm_alm_set ... > > > > rtctest.c:262:alarm_alm_set:Alarm time now set to 17:31:36. > > > > rtctest.c:267:alarm_alm_set:Expected -1 (-1) != rc (-1) > > > > alarm_alm_set: Test terminated by assertion > > > > FAIL rtc.alarm_alm_set > > > > not ok 5 rtc.alarm_alm_set > > > > > > > > The root cause is, the underlying EFI firmware doesn't support wakeup > > > > service (get/set alarm), while it doesn't have the EFI RT_PROP table > > > > either. As Ard Biesheuvel clarified [1], this breaks the UEFI spec, > > > > which requires EFI firmware to provide a 'RT_PROP' table if it doesn't > > > > support all runtime services (Section 4.6.2, UEFI spec 2.10). > > > > > > > > This issue was also reproduced on ARM server from another vendor, which > > > > doesn't have RT_PROP table either. This means, in real world, there are > > > > quite some platforms having this issue, that it doesn't support wakeup > > > > service while not providing a correct RT_PROP table, which makes it > > > > wrongly claimed to support it. > > > > > > > > Add a runtime check for the wakeup service to detect and correct this > > > > kind of cases. > > > > > > > > [1]. https://lore.kernel.org/lkml/CAMj1kXEkzXsjm0dPhzxB+KdtzqADd4NmafKmw2rKw7mAPBrgdA@mail.gmail.com/ > > > > > > > > Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com> > > > > --- > > > > drivers/rtc/rtc-efi.c | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > Thanks, I've queued this up now. > > > > > > > Actually, we might just remove the EFI get/set wakeup time > > functionality altogether, as it seems rather pointless to me to begin > > with. > > > > I'll send out an RFC shortly. > > I guess this is going to also solve the issue reported by loongson > https://lore.kernel.org/linux-rtc/20250613061747.4117470-1-wangming01@loongson.cn/ > > However, please let me take care of patches in my subsystem... > Apologies - I've dropped it now. But please don't queue this, I'll send out my RFC shortly.
On 2025/7/14 上午10:08, Ard Biesheuvel wrote: > On Fri, 11 Jul 2025 at 18:56, Alexandre Belloni > <alexandre.belloni@bootlin.com> wrote: >> >> On 11/07/2025 11:26:18+1000, Ard Biesheuvel wrote: >>> On Fri, 11 Jul 2025 at 11:06, Ard Biesheuvel <ardb@kernel.org> wrote: >>>> >>>> On Thu, 10 Jul 2025 at 18:41, Feng Tang <feng.tang@linux.alibaba.com> wrote: >>>>> >>>>> The kernel selftest of rtc reported a error on an ARM server which >>>>> use rtc-efi device: >>>>> >>>>> RUN rtc.alarm_alm_set ... >>>>> rtctest.c:262:alarm_alm_set:Alarm time now set to 17:31:36. >>>>> rtctest.c:267:alarm_alm_set:Expected -1 (-1) != rc (-1) >>>>> alarm_alm_set: Test terminated by assertion >>>>> FAIL rtc.alarm_alm_set >>>>> not ok 5 rtc.alarm_alm_set >>>>> >>>>> The root cause is, the underlying EFI firmware doesn't support wakeup >>>>> service (get/set alarm), while it doesn't have the EFI RT_PROP table >>>>> either. As Ard Biesheuvel clarified [1], this breaks the UEFI spec, >>>>> which requires EFI firmware to provide a 'RT_PROP' table if it doesn't >>>>> support all runtime services (Section 4.6.2, UEFI spec 2.10). >>>>> >>>>> This issue was also reproduced on ARM server from another vendor, which >>>>> doesn't have RT_PROP table either. This means, in real world, there are >>>>> quite some platforms having this issue, that it doesn't support wakeup >>>>> service while not providing a correct RT_PROP table, which makes it >>>>> wrongly claimed to support it. >>>>> >>>>> Add a runtime check for the wakeup service to detect and correct this >>>>> kind of cases. >>>>> >>>>> [1]. https://lore.kernel.org/lkml/CAMj1kXEkzXsjm0dPhzxB+KdtzqADd4NmafKmw2rKw7mAPBrgdA@mail.gmail.com/ >>>>> >>>>> Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com> >>>>> --- >>>>> drivers/rtc/rtc-efi.c | 4 +++- >>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>>> >>>> >>>> Thanks, I've queued this up now. >>>> >>> >>> Actually, we might just remove the EFI get/set wakeup time >>> functionality altogether, as it seems rather pointless to me to begin >>> with. >>> >>> I'll send out an RFC shortly. >> >> I guess this is going to also solve the issue reported by loongson >> https://lore.kernel.org/linux-rtc/20250613061747.4117470-1-wangming01@loongson.cn/ >> >> However, please let me take care of patches in my subsystem... >> > > Apologies - I've dropped it now. > > But please don't queue this, I'll send out my RFC shortly. > This is similar problem on Loongarch VM when running ltp testcase rtc02, I do not know whether the root cause is the same, the runtime service is hard to debug. Hope for RFC version :) Regards Bibo Mao
© 2016 - 2025 Red Hat, Inc.