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

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

[Greg Ociepka]

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 <greg@ferrisoft.com>
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)

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

[sashiko-bot]

> 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
> [ ... ]
> 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 <greg@ferrisoft.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260821181148.1642208-1-greg@ferrisoft.com?part=1

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

[Johan Hovold]

[ +CC: Konrad and Bjorn ]

On Fri, Aug 21, 2026 at 06:11:48PM +0200, Greg Ociepka wrote:
> 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.

This is intentional as "qcom,uefi-rtc-info" should not be set unless the
offset *is* stored (by the firmware) in said UEFI variable as documented
in the binding.

> 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:

Then the devicetree added by e8fbbca94db7 ("arm64: dts: qcom: glymur:
Add Asus Zenbook A16 (UX3607OA)") for 7.3 is incorrect and you should
drop the corresponding DT property.

>   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.

No, it's not. If your firmware doesn't use the EFI variable for the
offset then you need to figure out how the RTC is supposed to work on
these platforms (e.g. if you can set the time using some other measure
and should not be using an external offset all).

> 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.

No, this is a hack. And it, for example, prevents you from having the
RTC provide the same time in BIOS, Windows and Linux.

> 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")

The current driver is not buggy, it's working as intended so there
should be no Fixes tag.

> Signed-off-by: Greg Ociepka <greg@ferrisoft.com>
> 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)

Johan