[SRU][R][PATCH 0/2] RTC device disappears after updating to 7.0.0-39-generic (LP: #2169736)

[Roxana Nicolescu]

Acked-by: Roxana Nicolescu <roxana.nicolescu at canonical.com

On 07/10/2026 17:42, Edoardo Canepa via kernel-team wrote:
> BugLink: https://bugs.launchpad.net/bugs/2169736
>
> [ Impact ]
>
> Resolute carries "ACPI: x86: cmos_rtc: Create a CMOS RTC platform device"
> (via the 2026-09-22 upstream stable patchset, LP: #2167950) but is missing
> its companion commit "ACPI: x86/rtc-cmos: Use platform device for driver
> binding".
>
> As a result, on every x86 ACPI system (bare metal and VMs alike) the ACPI
> scan handler now creates a PNP0B00 platform device, which suppresses both
> the PNP enumeration of the CMOS RTC and the x86 fallback device, while
> rtc-cmos has no ACPI match table to bind to the new platform device.
> Nothing binds, so /dev/rtc0 no longer exists:
>
>    - hwclock: "Cannot access the Hardware Clock via any known method"
>    - rtcwake: "/dev/rtc0: unable to find device"
>    - timedatectl shows "RTC time: n/a"
>    - RTC wake alarms (CLOCK_REALTIME_ALARM/CLOCK_BOOTTIME_ALARM backed
>      wakeups, systemd WakeSystem= timers, suspend-then-hibernate) silently
>      lose the ability to wake the system
>    - the hardware clock can no longer be set or drift-corrected from
>      userspace
>
> Core timekeeping is not affected on x86 (boot time and the NTP 11-minute
> writeback use the direct-CMOS persistent-clock paths), which is why the
> regression is otherwise silent: no error is logged anywhere.
>
> [ Fix ]
>
> Cherry-pick from mainline (both in v7.1):
>
>    - 2a78e42104444f948698f1225deaf515e9b7224d
>      "ACPI: x86/rtc-cmos: Use platform device for driver binding"
>      (the commit dropped from the 2026-09-22 patchset; backported to
>      stable as 0a7a19286223 in v6.18.51)
>
>    - e9f850ba66cdf6b77fb4f005e46c4b605c4de434
>      "rtc: cmos: Use platform_get_irq_optional() in cmos_platform_probe()"
>      (Fixes-tagged follow-up for the newly enabled platform probe path;
>      in stable as 9811e2c321f7 since v6.18.53, so it would arrive with a
>      future stable update anyway)
>
> Both apply cleanly.
>
> [ Test Plan ]
>
> On an amd64 VM (QEMU q35) and/or bare metal:
>
>    1. Boot 7.0.0-39.39: /dev/rtc0 is absent, hwclock and rtcwake fail,
>       /sys/bus/platform/devices/PNP0B00:00 exists with no driver bound,
>       dmesg contains no rtc_cmos lines.
>    2. Boot 7.0.0-38.38 (control): /dev/rtc0 present via the PNP path.
>    3. Boot 7.0.0-39.39 with these two patches: /dev/rtc0 is back, rtc0
>       hangs off PNP0B00:00 with the driver symlink pointing at
>       platform/drivers/rtc_cmos, dmesg shows "rtc_cmos PNP0B00:00:
>       registered as rtc0" and the hctosys system clock line, and hwclock,
>       rtcwake and timedatectl work.
>
> Verified exactly as above with a CBD build of this series on the q35 VM.
>
> [ Where problems could occur ]
>
> The change is confined to how rtc-cmos binds on x86 ACPI systems: the RTC
> device moves from the PNP bus (/sys/bus/pnp, e.g. 00:03) to the platform
> bus (PNP0B00:00), matching upstream v7.1+ behaviour. Anything keying on
> the old PNP sysfs path could notice; standard consumers (udev's /dev/rtc
> symlink via the hctosys attribute, hwclock, rtcwake, timedatectl, wake
> alarms) were verified working. Non-x86 architectures are unaffected
> (drivers/acpi/x86 is x86-only), and systems without ACPI PNP0B00 keep
> using the existing fallback paths.
>