Raspberry Pi 5: RTC wakealarm works fine but /proc/driver/rtc shows alrm_pending: no

[AlessioFabianoRuffolo]

The alarm works perfectly for power-on, only the flag reporting is broken

Describe the bug

On Raspberry Pi 5, setting a wake-up alarm via /sys/class/rtc/rtc0/wakealarm successfully triggers a hardware power-on event from a shutdown state. However, the system status file /proc/driver/rtc does not correctly update the alrm_pending field, which remains stuck at no even when an alarm is active and correctly programmed in the hardware.

To reproduce

-Ensure POWER_OFF_ON_HALT=1 is set in the EEPROM config.

-Clear any existing alarms: echo 0 | sudo tee /sys/class/rtc/rtc0/wakealarm

-Set a new alarm for 5 minutes in the future: echo $(date -d '+5 minutes' +%s) | sudo tee /sys/class/rtc/rtc0 wakealarm

-Check the RTC driver status: cat /proc/driver/rtc | grep alrm

-Shutdown the system: sudo shutdown -h now

Expected behaviour

The command cat /proc/driver/rtc should show alrm_pending: yes after a successful write to wakealarm, confirming the PMIC has armed the wake-up event.

Actual behaviour

The command shows alrm_pending: no. Despite this "false negative" status, the Raspberry Pi 5 correctly wakes up at the scheduled time, proving the hardware received the instruction but the kernel/firmware status reporting is inconsistent.

System

_Which model of Raspberry Pi?_ Raspberry Pi 5

_Which OS and version?_ Raspberry Pi OS 64-bit - Raspberry Pi reference 2025-12-04

Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 4997bf4e4e49bc3305eb182a4a08bd023529da04, stage4
Which firmware version? 2025/12/08 19:29:54
Copyright (c) 2012 Broadcom
version 2226a853 (release) (embedded)

_Which kernel version?_ Linux User 6.12.62+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.62-1+rpt1 (2025-12-18) aarch64 GNU/Linux

Logs

cat /proc/driver/rtc output during the test:
Plaintext

rtc_time : 08:45:01
rtc_date : 2026-01-13
alrm_time : 08:50:00
alrm_date : 2026-01-13
alrm_pending: no <--- This is the incorrect status

Additional context

The issue persists even when using rtcwake or manual echo commands. It seems to be a reporting discrepancy between the PMIC/firmware and the Linux RTC driver interface. Tested with official 27W Power Supply.

[pelwell]

I think this is a simple deficiency in the Pi 5 RTC driver. Fixing it is likely to be easier than finding a battery to test it. Watch this space.

[pelwell]

This is more complex than previously thought. Can you point me at any documentation of the alrm_pending property? Do you have any examples of devices that cause this to be set correctly?

[pelwell]

To expand a bit, even with a modified Pi 5 RTC driver I can't find a way for the pending field that gets set in the struct rtc_wkalrm returned to the RTC framework to make its way into the output of cat /proc/driver/rtc. It just seems to get ignored.

[AlessioFabianoRuffolo]

Hi @pelwell, thanks for looking at my report. I have to admit, the one who found this bug was Gemini. It tried so many options with me on a personal whim that when we finally ran the final test, we realized it was (or at least thought it was) a bug. I also want to point out that Gemini helped me with both the report and the following answer. It put all the pieces together, as I'm completely new to this field.

Regarding your questions about the alrm_pending property:

1. Documentation: The /proc/driver/rtc output is generated by the generic RTC interface in the Linux kernel, specifically in drivers/rtc/rtc-proc.c. The code for the "pending" field usually looks like this: seq_printf(m, "alrm_pending\t: %s\n", str_yes_no(alrm.pending)); It relies on the rtc_read_alarm function, which populates the struct rtc_wkalrm.

2. Working Examples: The rtc-cmos driver (standard on x86 PCs) is the reference implementation. In rtc-cmos.c, the pending status is often tied to the RTC_AF (Alarm Flag) in the status register. If you have an old x86 machine or a device with a DS3231 (using rtc-ds1307.c), you can see alrm_pending: yes when the alarm time is reached but the interrupt hasn't been cleared.

3. The "Ignored Field" Issue: You are right, it is tricky. In many kernel versions, the pending field in rtc_wkalrm is only reflected in /proc if the underlying hardware/driver explicitly sets the pending bit during the read_alarm ops. If the Pi 5 PMIC (Power Management IC) clears the latch immediately upon wake-up or doesn't expose a "latched" alarm state to the kernel, the framework will always default to no.

Testing on my side: > I can confirm that while the Pi 5 successfully powers on at the scheduled time (so the hardware registers are definitely working), the OS never sees the state transition to pending: yes. This suggests that the handoff between the PMIC's internal alarm state and the Linux RTC framework might be missing the "latch" signal that rtc-proc.c expects.

4. The "Instantaneous Signal" Hypothesis: Since the Pi 5 successfully powers on/off exactly when requested, the RTC/PMIC is clearly hitting the target time. However, it’s possible that the PMIC clears the alarm status bit immediately upon triggering the power event.

If the pending state is transient and tied strictly to the power-toggle event, the kernel might be missing the window to capture it, or the PMIC might not be "latching" the interrupt flag for the OS to see after the boot.

Is it possible that on the Pi 5, the pending status is only valid in the interval between the alarm being set and the alarm firing, and then it's automatically cleared by hardware? This would explain why we always see no once the OS is up and running.

Testing on my side: > I can confirm that while the Pi 5 successfully powers on at the scheduled time (so the hardware registers are definitely working), the OS never sees the state transition to pending: yes. This suggests that the handoff between the PMIC's internal alarm state and the Linux RTC framework might be missing the "latch" signal that rtc-proc.c expects.

Is it possible that the PMIC clears the alarm status bit before the kernel has a chance to read it during the boot sequence?

I truly hope you find what we think might happen and what we've found helpful. I remain at your disposal.

[pelwell]

Working Examples: The rtc-cmos driver (standard on x86 PCs) is the reference implementation. In rtc-cmos.c, the pending status is often tied to the RTC_AF (Alarm Flag) in the status register. If you have an old x86 machine or a device with a DS3231 (using rtc-ds1307.c), you can see alrm_pending: yes when the alarm time is reached but the interrupt hasn't been cleared.

Is this from personal experience, or is this Gemini? I think the RTC framework has been broken in this regard since raspberrypi/linux@6610e08 (which is now 15 years old).

I now have 3 sets of patches to make the pending flag behave correctly (I think - I didn't find any documentation):

• 1 for the Pi 5 EEPROM,
• 1 for the rpi-rtc driver, and
• 1 for the RTC framework.

I believe that all 3 are required, but I would be very happy to find a solution that didn't require a change to common kernel code, hence my desire to find an RTC driver that works in this respect.

[pelwell]

From what I can see, the rtc-cmos driver only ever sets the pending flag in struct rtc_wkalrm to 0, so this looks like a strange example to choose. ds1337_read_alarm, which is what should be used to read the alarm on a DS3231, does at least set the .pending flag based on a register value, but the RTC framework then ignores it.

[pelwell]

Pull Request raspberrypi/linux#7198 contains the required kernel changes, a link to the required EEPROM update, and instructions on how to install both.