lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250423075143.11157-1-johan+linaro@kernel.org>
Date: Wed, 23 Apr 2025 09:51:39 +0200
From: Johan Hovold <johan+linaro@...nel.org>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>,
	Bjorn Andersson <andersson@...nel.org>
Cc: Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Konrad Dybcio <konradybcio@...nel.org>,
	linux-arm-msm@...r.kernel.org,
	linux-rtc@...r.kernel.org,
	devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Johan Hovold <johan+linaro@...nel.org>
Subject: [PATCH 0/4] rtc: pm8xxx: fix uefi offset lookup

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ