Re: [PATCH 1/2] rtc: cmos: Disable ACPI RTC event before handling it

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] RTC wakeup events are permanently lost if the ACPI SCI handler executes before the device resume callback and the BIOS has cleared the RTC control registers.
--

commit 8ca107b659080f6c7d65133bba3bda531b0c4968
Author: Gregory Price <gourry@gourry.net>

rtc: cmos: Disable ACPI RTC event before handling it

This commit resolves an issue where rtc-cmos alarm events are missed due to a
race condition with the ACPI SCI handler. It clears and disables the ACPI RTC
event before scheduling the irqwork so the worker can safely enable the next
event without interference.

> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index fa04ece151b8b..fe514b1aa3433 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -758,7 +758,9 @@ static u32 rtc_handler(void *context)
>  	unsigned char rtc_intr;
>  	unsigned long flags;
>  
> -
> +	/* Quiesce this event before rtc->irqwork can arm the next one. */
> +	acpi_clear_event(ACPI_EVENT_RTC);
> +	acpi_disable_event(ACPI_EVENT_RTC, 0);

[Severity: High]
This isn't a bug introduced by this patch, but this unconditional clearing of
the ACPI event status appears to permanently lose RTC wakeup events under
certain conditions.

If the system suspends with the RTC alarm enabled (cmos_rtc.suspend_ctrl has
RTC_AIE set) and use_acpi_alarm is false, the BIOS can clear the RTC_CONTROL
register during the suspend/resume cycle.

When the system wakes, the ACPI SCI handler rtc_handler() runs before
cmos_resume(). Because rtc_handler() clears the ACPI event status
unconditionally, it reads the cleared register and fails to call
rtc_update_irq():

rtc_handler() {
    ...
    if (cmos_rtc.suspend_ctrl)
        rtc_control = CMOS_READ(RTC_CONTROL);
    if (rtc_control & RTC_AIE) {
        ...
        rtc_update_irq(...);
    }
}

Later, cmos_resume() runs and attempts to recover the lost event by calling
cmos_check_acpi_rtc_status(). However, since rtc_handler() already cleared the
ACPI event status, acpi_get_event_status() returns no event, and the IRQ is
permanently lost.

Will this indefinitely stall userspace processes waiting for the RTC alarm
via poll() on /dev/rtc?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909225132.1392883-1-gourry@gourry.net?part=1