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

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-prev] [day] [month] [year] [list]

Message-ID: <aBsRxbBb91e_sQn3@hovoldconsulting.com>
Date: Wed, 7 May 2025 09:54:45 +0200
From: Johan Hovold <johan@...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
Subject: Re: [PATCH 0/4] rtc: pm8xxx: fix uefi offset lookup

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