Surface Pro 8: RTC writes never persist — SRTC (ACPI000E) implements no _GRT/_SRT, is there any other channel?

Related: #1658 (SP7+, same symptom), #415 (SP7, same symptom, acpi_tad investigated), #1497 (SP8, clock lost on power off)

Summary

On Surface Pro 8, nothing written to the RTC from Linux survives a power cycle. The
firmware appears to overwrite rtc0 at POST from its own clock, which drifts freely.
The only working correction is setting the time manually in the UEFI setup screen.

This is already known empirically from the issues above. What I think is new here is
the ACPI-level reason: the SRTC device declares itself as ACPI000E but implements
neither _GRT nor _SRT, so there is no ACPI path to read or write that clock at all.
I'd like to know whether a SAM-level path exists instead, before people keep chasing
this.

Measured drift

Roughly 15m40s accumulated over a few months without correction. Measured on a single
boot as the difference between the RTC value the kernel read at boot and the true boot
instant reconstructed after NTP sync:

$ journalctl -b | grep 'setting system clock'
Aug 27 10:05:20 kernel: rtc_cmos rtc_cmos: setting system clock to 2026-08-27T08:05:20 UTC

$ uptime -s
2026-08-27 10:21:01

10:21:01 - 10:05:20 = 15m41s. The user-visible symptom is the wrong time on the
display manager greeter until systemd-timesyncd syncs (which took ~2 minutes here,
Wi-Fi coming up late), and permanently wrong time in the UEFI setup screen.

The two RTCs

rtc0 -> rtc_cmos
rtc1 -> acpi-tad ACPI000E:00

rtc0 is writable and is correct during runtime — the kernel's NTP 11-minute mode
keeps rewriting it, and hwclock --systohc works on it without error. It just gets
discarded before Linux reads it on the next boot.

rtc1 fails on every access, via both interfaces:

$ sudo hwclock -r -f /dev/rtc1
hwclock: ioctl(3, RTC_UIE_ON, 0) to /dev/rtc1 failed: Input/output error

$ sudo hwclock --systohc --noadjfile --utc -f /dev/rtc1 --verbose
RTC type: 'acpi-tad'
Setting Hardware Clock to 08:34:58 = 1787819698 seconds since 1969
hwclock: ioctl(RTC_SET_TIME) to /dev/rtc1 to set the time failed: Input/output error

$ cat /sys/bus/platform/devices/ACPI000E:00/time
cat: .../time: Input/output error

[    4.295206] acpi-tad ACPI000E:00: Missing _PRW
[    4.299486] acpi-tad ACPI000E:00: registered as rtc1

Why: the ACPI methods do not exist

Dumping and disassembling all tables (acpidump -b, DSDT + 17 SSDTs), ACPI000E appears
only in SSDT7, and grepping every table for _GRT or _SRT returns nothing. Here is
the complete device body:

Device (SRTC)
{
    Name (SGCP, 0x000001F7)
    Name (_SUB, "MSHW0214")  // _SUB: Subsystem ID
    Method (_HID, 0, NotSerialized)  // _HID: Hardware ID
    {
        Return ("ACPI000E")
    }

    Method (_STA, 0, NotSerialized)  // _STA: Status
    {
        Return (0x0F)
    }

    Method (_GCP, 0, NotSerialized)  // _GCP: Get Capabilities
    {
        Return (SGCP) /* \_SB_.SRTC.SGCP */
    }

    Method (_GWS, 1, Serialized)  // _GWS: Get Wake Status
    {
        If ((Arg0 == Zero))
        {
            Return (GWAS) /* \GWAS */
        }

        If ((Arg0 == One))
        {
            Return (GWDS) /* \GWDS */
        }

        Return (Zero)
    }
}

No OperationRegion, no fields, no _GRT, no _SRT. _GCP returns a hardcoded
0x1F7. So on this device SRTC is a timed-wake/alarm device, not an OS-accessible
clock — the EIO is simply "method not present", and there is nothing for an SSDT
override to hook into either, since no hardware access path is described anywhere in
the tables.

Possible small acpi_tad issue as a side note: the driver creates the time sysfs
attribute (and registers an RTC) based on the capability bit returned by _GCP,
without checking that _GRT/_SRT actually exist. That produces an rtc1 that
always fails, which is what sent both #415 and me down this path. Checking for the
methods at probe time would make the situation self-evident. Happy to report that
separately to linux-acpi if it's considered worth fixing.

The actual question

Since ACPI is a dead end here, is the authoritative clock maintained by SAM?

_SUB = MSHW0214 looks like it belongs to the Microsoft device family, which made me
wonder. But the kernel SSAM documentation lists battery, thermal sensors, cooling and
performance mode, fans, HID, tablet mode — nothing about time. And on this machine the
registered SAM devices only cover categories 0x02, 0x03, 0x0e and 0x15:

$ ls /sys/bus/surface_aggregator/devices/
00:00:01:0e:00  01:02:01:01:00  01:02:01:01:01  01:03:01:00:01  01:0e:01:00:01
01:15:01:06:00  01:15:01:07:00  01:15:02:01:00  01:15:02:02:00  01:15:02:03:00
01:15:02:05:00

So my questions:

1. Is there a known SSAM request for reading/setting the RTC, in any target category?
2. If not — is it known how Windows keeps this clock correct on SP8? If Windows also
   only writes the CMOS RTC, then the "firmware overwrites rtc0 at POST" model would
   be wrong and something else is going on.
3. Is it worth documenting in the wiki that manual UEFI correction is the only option
   on SP7/SP7+/SP8, so people stop rediscovering this?

I have surface_aggregator_cdev available and I'm willing to run any specific request
you consider safe, but I'm deliberately not brute-forcing the command space on a
controller that handles charging and thermals.

Environment

• Surface Pro 8, no Windows partition, Secure Boot enabled with own keys (sbctl),
  LUKS root unlocked via TPM2
• Kernel: 7.1.9-arch1-2 (stock Arch). linux-surface 6.19.8 also installed and can be
  booted if a comparison is useful — note BUG: rtc can't be changed from system #1658 reports the same behaviour on a
  -surface kernel
• Firmware: fully up to date as of today (UEFI 553675407, ME 4027257346,
  SAM 201352331), applied from SurfacePro8_Win11_22631_26.073.32221.0.msi
• timedatectl: RTC in local TZ: no; NTP active; system clock synchronized
• Kernel lockdown is integrity (Secure Boot), so fwts uefirttime aborts; and
  CONFIG_EFI_TEST is not set in either kernel, so EFI SetTime() is untested