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

[Edoardo Canepa]

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.