[PATCH 0/4] rtc: pm8xxx: fix uefi offset lookup

[PATCH 0/4] rtc: pm8xxx: fix uefi offset lookup

[Johan Hovold]

On many Qualcomm platforms the PMIC RTC control and time registers are
read-only so that the RTC time can not be updated. Instead an offset
needs be stored in some machine-specific non-volatile memory, which a
driver can take into account.

On platforms where the offset is stored in a Qualcomm specific UEFI
variable the variables are also accessed in a non-standard way, which
means that the OS cannot assume that the variable service is available
by the time the driver probes.

This series adds a 'qcom,uefi-rtc-info' boolean DT property to indicate
that the RTC offset is stored in a Qualcomm specific UEFI variable so
that the OS can determine whether to wait for it to become available.

I used such a property in v1 of the series adding support for the UEFI
offset [1], but mistakenly convinced myself that it was not needed given
that the efivars driver would need to remain built in. As Rob Clark
noticed, this is however not sufficient and the driver can currently
fail to look up the offset if the RTC driver is built in or if a
dependency of the efivars driver is built as a module. [2]

As with the rest of this driver, hopefully all of this goes away (for
future platforms) once Qualcomm fix their UEFI implementation so that
the time service can be used directly.

Preferably the binding and driver fix can be merged for 6.15-rc by
Alexandre, while Bjorn takes the DT changes through the branch which has
the DT patches from v2 (which unfortunately missed 6.15 but may possibly
be sent as hw enablement fixups). [3]

Johan


[1] https://lore.kernel.org/all/20250120144152.11949-1-johan+linaro@kernel.org/
[2] https://lore.kernel.org/all/aAecIkgmTTlThKEZ@hovoldconsulting.com/
[3] https://lore.kernel.org/lkml/20250219134118.31017-1-johan+linaro@kernel.org/

Johan Hovold (4):
  dt-bindings: rtc: qcom-pm8xxx: add uefi-variable offset
  rtc: pm8xxx: fix uefi offset lookup
  arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset
  arm64: dts: qcom: x1e80100: describe uefi rtc offset

 .../bindings/rtc/qcom-pm8xxx-rtc.yaml           |  6 ++++++
 .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts  |  2 ++
 arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi    |  1 +
 drivers/rtc/rtc-pm8xxx.c                        | 17 ++++++++++++-----
 4 files changed, 21 insertions(+), 5 deletions(-)

-- 
2.49.0

[PATCH 1/4] dt-bindings: rtc: qcom-pm8xxx: add uefi-variable offset

[Johan Hovold]

On many Qualcomm platforms the PMIC RTC control and time registers are
read-only so that the RTC time can not be updated. Instead an offset
needs be stored in some machine-specific non-volatile memory, which a
driver can take into account.

On platforms where the offset is stored in a Qualcomm specific UEFI
variable the variables are also accessed in a non-standard way, which
means that the OS cannot assume that the variable service is available
by the time the RTC driver probes.

Add a 'qcom,uefi-rtc-info' boolean flag to indicate that the RTC offset
is stored in a Qualcomm specific UEFI variable so that the OS can
determine whether to wait for it to become available.

The UEFI variable is

	882f8c2b-9646-435f-8de5-f208ff80c1bd-RTCInfo

and holds a 12-byte structure where the first four bytes is a GPS time
offset in little-endian byte order.

Link: https://lore.kernel.org/all/aAecIkgmTTlThKEZ@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
---
 Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
index 68ef3208c886..7497dc3ac5b2 100644
--- a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
@@ -55,6 +55,12 @@ properties:
     description:
       RTC alarm is not owned by the OS
 
+  qcom,uefi-rtc-info:
+    type: boolean
+    description:
+      RTC offset is stored as a four-byte GPS time offset in a 12-byte UEFI
+      variable 882f8c2b-9646-435f-8de5-f208ff80c1bd-RTCInfo
+
   wakeup-source: true
 
 required:
-- 
2.49.0

Re: [PATCH 1/4] dt-bindings: rtc: qcom-pm8xxx: add uefi-variable offset

[Rob Herring (Arm)]

On Wed, 23 Apr 2025 09:51:40 +0200, Johan Hovold wrote:
> On many Qualcomm platforms the PMIC RTC control and time registers are
> read-only so that the RTC time can not be updated. Instead an offset
> needs be stored in some machine-specific non-volatile memory, which a
> driver can take into account.
> 
> On platforms where the offset is stored in a Qualcomm specific UEFI
> variable the variables are also accessed in a non-standard way, which
> means that the OS cannot assume that the variable service is available
> by the time the RTC driver probes.
> 
> Add a 'qcom,uefi-rtc-info' boolean flag to indicate that the RTC offset
> is stored in a Qualcomm specific UEFI variable so that the OS can
> determine whether to wait for it to become available.
> 
> The UEFI variable is
> 
> 	882f8c2b-9646-435f-8de5-f208ff80c1bd-RTCInfo
> 
> and holds a 12-byte structure where the first four bytes is a GPS time
> offset in little-endian byte order.
> 
> Link: https://lore.kernel.org/all/aAecIkgmTTlThKEZ@hovoldconsulting.com/
> Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
> ---
>  Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

[PATCH 2/4] rtc: pm8xxx: fix uefi offset lookup

[Johan Hovold]

On many Qualcomm platforms the PMIC RTC control and time registers are
read-only so that the RTC time can not be updated. Instead an offset
needs be stored in some machine-specific non-volatile memory, which a
driver can take into account.

On platforms where the offset is stored in a Qualcomm specific UEFI
variable the variables are also accessed in a non-standard way, which
means that the OS cannot assume that the variable service is available
by the time the driver probes.

Use the new 'qcom,uefi-rtc-info' property to determine whether to probe
defer until the UEFI offset becomes available so that the offset can be
used also when the RTC driver is built in or when a dependency of the
UEFI variable driver is built as a module (e.g. the driver for the SCM
interconnects).

Fixes: bba38b874886 ("rtc: pm8xxx: add support for uefi offset")
Reported-by: Rob Clark <robdclark@gmail.com>
Link: https://lore.kernel.org/lkml/CAF6AEGsfke=x0p1b2-uNX6DuQfRyEjVbJaxTbVLDT2YvSkGJbg@mail.gmail.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
---
 drivers/rtc/rtc-pm8xxx.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-pm8xxx.c b/drivers/rtc/rtc-pm8xxx.c
index 3c1dddcc81df..5da237e7b9b2 100644
--- a/drivers/rtc/rtc-pm8xxx.c
+++ b/drivers/rtc/rtc-pm8xxx.c
@@ -576,13 +576,20 @@ static int pm8xxx_rtc_probe_offset(struct pm8xxx_rtc *rtc_dd)
 	}
 
 	/* Use UEFI storage as fallback if available */
-	if (efivar_is_available()) {
-		rc = pm8xxx_rtc_read_uefi_offset(rtc_dd);
-		if (rc == 0)
-			rtc_dd->use_uefi = true;
+	rtc_dd->use_uefi = of_property_read_bool(rtc_dd->dev->of_node,
+						 "qcom,uefi-rtc-info");
+	if (!rtc_dd->use_uefi)
+		return 0;
+
+	if (!efivar_is_available()) {
+		if (IS_ENABLED(CONFIG_EFI))
+			return -EPROBE_DEFER;
+
+		dev_warn(rtc_dd->dev, "efivars not available\n");
+		rtc_dd->use_uefi = false;
 	}
 
-	return 0;
+	return pm8xxx_rtc_read_uefi_offset(rtc_dd);
 }
 
 static int pm8xxx_rtc_probe(struct platform_device *pdev)
-- 
2.49.0

[PATCH 3/4] arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset

[Johan Hovold]

On many Qualcomm platforms the PMIC RTC control and time registers are
read-only so that the RTC time can not be updated. Instead an offset
needs be stored in some machine-specific non-volatile memory, which a
driver can take into account.

On platforms where the offset is stored in a Qualcomm specific UEFI
variable the variables are also accessed in a non-standard way, which
means that the OS cannot assume that the variable service is available
by the time the RTC driver probes.

Use the new 'qcom,uefi-rtc-info' property to indicate that the offset is
stored in a UEFI variable so that the OS can determine whether to wait
for it to become available.

Fixes: 409803681a55 ("arm64: dts: qcom: sc8280xp-x13s: switch to uefi rtc offset")
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
---
 arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index 8000254f4db5..66c39765225f 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -1090,6 +1090,8 @@ &pmk8280_pon_resin {
 };
 
 &pmk8280_rtc {
+	qcom,uefi-rtc-info;
+
 	status = "okay";
 };
 
-- 
2.49.0

[PATCH 4/4] arm64: dts: qcom: x1e80100: describe uefi rtc offset

[Johan Hovold]

On many Qualcomm platforms the PMIC RTC control and time registers are
read-only so that the RTC time can not be updated. Instead an offset
needs be stored in some machine-specific non-volatile memory, which a
driver can take into account.

On platforms where the offset is stored in a Qualcomm specific UEFI
variable the variables are also accessed in a non-standard way, which
means that the OS cannot assume that the variable service is available
by the time the RTC driver probes.

Use the new 'qcom,uefi-rtc-info' property to indicate that the offset is
stored in a UEFI variable so that the OS can determine whether to wait
for it to become available.

Fixes: b53c2c23d3c2 ("arm64: dts: qcom: x1e80100: enable rtc")
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
---
 arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi b/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi
index a59aa8e7642d..5a170238e74d 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi
@@ -224,6 +224,7 @@ pmk8550_rtc: rtc@6100 {
 			reg-names = "rtc", "alarm";
 			interrupts = <0x0 0x62 0x1 IRQ_TYPE_EDGE_RISING>;
 			qcom,no-alarm; /* alarm owned by ADSP */
+			qcom,uefi-rtc-info;
 		};
 
 		pmk8550_sdam_2: nvram@7100 {
-- 
2.49.0

Re: [PATCH 0/4] rtc: pm8xxx: fix uefi offset lookup

[Johan Hovold]

Hi Alexandre and Bjorn,

On Wed, Apr 23, 2025 at 09:51:39AM +0200, Johan Hovold wrote:
> On many Qualcomm platforms the PMIC RTC control and time registers are
> read-only so that the RTC time can not be updated. Instead an offset
> needs be stored in some machine-specific non-volatile memory, which a
> driver can take into account.
> 
> On platforms where the offset is stored in a Qualcomm specific UEFI
> variable the variables are also accessed in a non-standard way, which
> means that the OS cannot assume that the variable service is available
> by the time the driver probes.
> 
> This series adds a 'qcom,uefi-rtc-info' boolean DT property to indicate
> that the RTC offset is stored in a Qualcomm specific UEFI variable so
> that the OS can determine whether to wait for it to become available.
> 
> I used such a property in v1 of the series adding support for the UEFI
> offset [1], but mistakenly convinced myself that it was not needed given
> that the efivars driver would need to remain built in. As Rob Clark
> noticed, this is however not sufficient and the driver can currently
> fail to look up the offset if the RTC driver is built in or if a
> dependency of the efivars driver is built as a module. [2]
> 
> As with the rest of this driver, hopefully all of this goes away (for
> future platforms) once Qualcomm fix their UEFI implementation so that
> the time service can be used directly.
> 
> Preferably the binding and driver fix can be merged for 6.15-rc by
> Alexandre, while Bjorn takes the DT changes through the branch which has
> the DT patches from v2 (which unfortunately missed 6.15 but may possibly
> be sent as hw enablement fixups). [3]

It seems we won't have RTC support in 6.15, but could you please pick
these up for 6.16 to make sure that the RTC works also when the driver
is built in?

> [1] https://lore.kernel.org/all/20250120144152.11949-1-johan+linaro@kernel.org/
> [2] https://lore.kernel.org/all/aAecIkgmTTlThKEZ@hovoldconsulting.com/
> [3] https://lore.kernel.org/lkml/20250219134118.31017-1-johan+linaro@kernel.org/
> 
> Johan Hovold (4):
>   dt-bindings: rtc: qcom-pm8xxx: add uefi-variable offset
>   rtc: pm8xxx: fix uefi offset lookup
>   arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset
>   arm64: dts: qcom: x1e80100: describe uefi rtc offset

Johan

Re: [PATCH 0/4] rtc: pm8xxx: fix uefi offset lookup

[Johan Hovold]

Hi Alexandre,

On Wed, May 07, 2025 at 09:54:46AM +0200, Johan Hovold wrote:
> Hi Alexandre and Bjorn,
> 
> On Wed, Apr 23, 2025 at 09:51:39AM +0200, Johan Hovold wrote:

> > This series adds a 'qcom,uefi-rtc-info' boolean DT property to indicate
> > that the RTC offset is stored in a Qualcomm specific UEFI variable so
> > that the OS can determine whether to wait for it to become available.
> > 
> > I used such a property in v1 of the series adding support for the UEFI
> > offset [1], but mistakenly convinced myself that it was not needed given
> > that the efivars driver would need to remain built in. As Rob Clark
> > noticed, this is however not sufficient and the driver can currently
> > fail to look up the offset if the RTC driver is built in or if a
> > dependency of the efivars driver is built as a module. [2]

> > Preferably the binding and driver fix can be merged for 6.15-rc by
> > Alexandre, while Bjorn takes the DT changes through the branch which has
> > the DT patches from v2 (which unfortunately missed 6.15 but may possibly
> > be sent as hw enablement fixups). [3]
> 
> It seems we won't have RTC support in 6.15, but could you please pick
> these up for 6.16 to make sure that the RTC works also when the driver
> is built in?

It's only been two weeks since my last last reminder about this series,
but can you please pick up the binding and driver patches for 6.16?

Bjorn has already sent his DT changes for 6.16, but since these are
fixes he should be able to get them in during the 6.16 cycle.

It would help a lot if the driver changes are in place then.

> > [1] https://lore.kernel.org/all/20250120144152.11949-1-johan+linaro@kernel.org/
> > [2] https://lore.kernel.org/all/aAecIkgmTTlThKEZ@hovoldconsulting.com/
> > [3] https://lore.kernel.org/lkml/20250219134118.31017-1-johan+linaro@kernel.org/
> > 
> > Johan Hovold (4):
> >   dt-bindings: rtc: qcom-pm8xxx: add uefi-variable offset
> >   rtc: pm8xxx: fix uefi offset lookup
> >   arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset
> >   arm64: dts: qcom: x1e80100: describe uefi rtc offset

Johan

Re: (subset) [PATCH 0/4] rtc: pm8xxx: fix uefi offset lookup

[Alexandre Belloni]

On Wed, 23 Apr 2025 09:51:39 +0200, Johan Hovold wrote:
> On many Qualcomm platforms the PMIC RTC control and time registers are
> read-only so that the RTC time can not be updated. Instead an offset
> needs be stored in some machine-specific non-volatile memory, which a
> driver can take into account.
> 
> On platforms where the offset is stored in a Qualcomm specific UEFI
> variable the variables are also accessed in a non-standard way, which
> means that the OS cannot assume that the variable service is available
> by the time the driver probes.
> 
> [...]

Applied, thanks!

[1/4] dt-bindings: rtc: qcom-pm8xxx: add uefi-variable offset
      https://git.kernel.org/abelloni/c/b23b91d56863
[2/4] rtc: pm8xxx: fix uefi offset lookup
      https://git.kernel.org/abelloni/c/ead453283279

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: (subset) [PATCH 0/4] rtc: pm8xxx: fix uefi offset lookup

[Bjorn Andersson]

On Wed, 23 Apr 2025 09:51:39 +0200, Johan Hovold wrote:
> On many Qualcomm platforms the PMIC RTC control and time registers are
> read-only so that the RTC time can not be updated. Instead an offset
> needs be stored in some machine-specific non-volatile memory, which a
> driver can take into account.
> 
> On platforms where the offset is stored in a Qualcomm specific UEFI
> variable the variables are also accessed in a non-standard way, which
> means that the OS cannot assume that the variable service is available
> by the time the driver probes.
> 
> [...]

Applied, thanks!

[3/4] arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset
      commit: 869971de8221b97acb6aa4d7ff4fa67eb71adc87
[4/4] arm64: dts: qcom: x1e80100: describe uefi rtc offset
      commit: e8d3dc45f2d3b0fea089e0e6e351d1287a5a2a29

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>