[PATCH] rtc: pm8xxx: do not fail probe when UEFI offset variable is missing

On machines using "qcom,uefi-rtc-info" the Unix epoch offset for the
read-only PMIC RTC counter lives in the RTCInfo UEFI variable. The
driver reads it at probe time and treats every failure as fatal,
including EFI_NOT_FOUND.

That turns a merely-uninitialized clock into a permanently absent one
on firmware that never creates the variable. The ASUS Zenbook A16
(UX3607OA, Snapdragon X2 Elite Extreme "Glymur", InsydeH2O UEFI) is
such a machine: qseecom and uefisecapp come up fine, other variables
in the same Qualcomm vendor GUID (882f8c2b-9646-435f-8de5-f208ff80c1bd)
exist and are readable, but among the 110 variables exposed through
efivarfs there is no RTCInfo -- and Windows on the same machine does
not create one either. Probe then fails:

  rtc-pm8xxx c426000.spmi:pmic@0:rtc@6100: probe with driver rtc-pm8xxx
      failed with error -2

This is a chicken-and-egg failure: pm8xxx_rtc_write_uefi_offset()
would create the variable (the set path uses EFI_VARIABLE_NON_VOLATILE
attributes and efivar_set_variable() creates missing variables), but
it can only run from the RTC set_time path -- and the RTC device never
registers because probe failed. The variable can never come into
existence.

Treat a missing variable like an unset clock instead: warn, keep the
zero offset, and register the RTC. Reads expose the raw counter until
the first clock set (typically the NTP-triggered RTC synchronization)
computes the offset and creates the variable; from then on the machine
keeps time across reboots. Userspace already copes with an implausible
RTC value at boot -- systemd only steps the clock forward from its
persistent timestamp.

Other read errors still fail the probe as before.

Verified on the Zenbook A16 across consecutive boots: on the first
boot the driver warns, registers rtc0 and sets the system clock from
the raw counter (1970-01-04 here -- the counter had been running for
three days); the first NTP-triggered clock set creates RTCInfo; every
following boot restores correct wall time from the RTC before any
network is up.

Fixes: bba38b874886 ("rtc: pm8xxx: add support for uefi offset")
Signed-off-by: Greg Ociepka <[email protected]>
Assisted-by: Claude:fable-5
---
 drivers/rtc/rtc-pm8xxx.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-pm8xxx.c b/drivers/rtc/rtc-pm8xxx.c
index e624f84..4627f4e 100644
--- a/drivers/rtc/rtc-pm8xxx.c
+++ b/drivers/rtc/rtc-pm8xxx.c
@@ -589,7 +589,21 @@ static int pm8xxx_rtc_probe_offset(struct pm8xxx_rtc *rtc_dd)
 		rtc_dd->use_uefi = false;
 	}
 
-	return pm8xxx_rtc_read_uefi_offset(rtc_dd);
+	rc = pm8xxx_rtc_read_uefi_offset(rtc_dd);
+	if (rc == -ENOENT) {
+		/*
+		 * The variable does not exist until something stores an
+		 * offset: pm8xxx_rtc_write_uefi_offset() creates it on the
+		 * first clock set. Keep probing with a zero offset instead
+		 * of failing -- otherwise the RTC never registers and the
+		 * variable can never come into existence.
+		 */
+		dev_warn(rtc_dd->dev,
+			 "UEFI offset variable not found, will be created on first clock set\n");
+		return 0;
+	}
+
+	return rc;
 }
 
 static int pm8xxx_rtc_probe(struct platform_device *pdev)