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

[Manuel Diewald]

On Thu, Oct 08, 2026 at 01:10:48AM +0200, 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 the remainder of the mainline series (all 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)
> 
>   - d15f1c2e413e861270ca6aa5dc5d9da1bcd678ca
>     "ACPI: PNP: Drop CMOS RTC PNP device support"
>     (series tail; removes the now-dead is_cmos_rtc_device() PNP check.
>     Required: without it, acpi_pnp.c references the x86-only
>     cmos_rtc_platform_device_present symbol and arm64 fails to link)
> 
>   - 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)
> 
> All apply cleanly.
> 
> v3: no code changes; resent as a new thread, the v2 posting got
> threaded into v1.
> v2: added "ACPI: PNP: Drop CMOS RTC PNP device support" — v1 broke the
> arm64 build (undefined reference to cmos_rtc_platform_device_present in
> acpi_pnp.c); with the full series, amd64/arm64/armhf/s390x/ppc64el all
> build.
> 
> [ 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 this series applied: /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 at
> runtime: the rtc-cmos/x86 changes compile only on x86, and the
> acpi_pnp.c change only removes an x86-only CMOS RTC device-ID check
> (builds verified on amd64/arm64/armhf/s390x/ppc64el). Systems without
> ACPI PNP0B00 keep using the existing fallback paths.
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

Acked-by: Manuel Diewald <manuel.diewald at canonical.com>

-- 
 Manuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20261008/c1f0ae66/attachment.sig>