On Mon, 2 Jan 2023 at 23:21, Alexandre Belloni
<alexandre.belloni@xxxxxxxxxxx> wrote:
>
> On 02/01/2023 11:47:11+0100, Ard Biesheuvel wrote:
> > On Tue, 27 Dec 2022 at 05:09, Shanker Donthineni <sdonthineni@xxxxxxxxxx> wrote:
> > >
> > > The current implementation of rtc-efi is expecting all the 4
> > > time services GET{SET}_TIME{WAKEUP} must be supported by UEFI
> > > firmware. As per the EFI_RT_PROPERTIES_TABLE, the platform
> > > specific implementations can choose to enable selective time
> > > services based on the RTC device capabilities.
> > >
> > > This patch does the following changes to provide GET/SET RTC
> > > services on platforms that do not support the WAKEUP feature.
> > >
> > > 1) Relax time services cap check when creating a platform device.
> > > 2) Clear RTC_FEATURE_ALARM bit in the absence of WAKEUP services.
> > > 3) Conditional alarm entries in '/proc/driver/rtc'.
> > >
> > > Signed-off-by: Shanker Donthineni <sdonthineni@xxxxxxxxxx>
> >
> > Queued as a fix in efi/urgent, thanks.
>
> This rather seems like an rtc heavy patch and the subject line is
> misleading. This should be rtc: efi:
> Also, I'm pretty sure this doesn't qualify as an urgent fix.
>
I'm happy to drop it from my tree, but please add a cc:stable so it
gets backported to v6.1 at least. Otherwise, EFI compliant systems
that implement get/set_time but not get/set_wakeup_time have no RTC at
all on any LTS kernel until a year from now, and this was never the
intent when we introduced the EFI_RT_PROPERTIES_TABLE.
