linux-kernel - Re: [PATCH 0/7] arm64: dts: qcom: x1e80100: enable rtc

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: <aAecIkgmTTlThKEZ@hovoldconsulting.com>
Date: Tue, 22 Apr 2025 15:39:46 +0200
From: Johan Hovold <johan@...nel.org>
To: Rob Clark <robdclark@...il.com>
Cc: Rob Herring <robh@...nel.org>, Johan Hovold <johan+linaro@...nel.org>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	Bjorn Andersson <andersson@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Konrad Dybcio <konradybcio@...nel.org>,
	Jonathan Marek <jonathan@...ek.ca>, linux-arm-msm@...r.kernel.org,
	linux-rtc@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, Rob Clark <robdclark@...omium.org>
Subject: Re: [PATCH 0/7] arm64: dts: qcom: x1e80100: enable rtc

On Mon, Apr 21, 2025 at 07:36:28AM -0700, Rob Clark wrote:
> On Sun, Jan 26, 2025 at 4:20 PM Rob Herring <robh@...nel.org> wrote:
> > On Mon, Jan 20, 2025 at 03:41:45PM +0100, Johan Hovold wrote:
> > > This series adds support for utilising the UEFI firmware RTC offset to
> > > the Qualcomm PMIC RTC driver and uses that to enable the RTC on all X
> > > Elite machines.

> > > Rob had some concerns about adding a DT property for indicating that a
> > > machine uses UEFI for storing the offset and suggested that the driver
> > > should probe for this instead. Unfortunately, this is easier said than
> > > done given that UEFI variable support itself is probed for and may not
> > > be available until after the RTC driver probes.
> >
> > This information would be useful in the binding commit...
> >
> > Seems like something I would say, but this is v1 and I have no memory of
> > discussing this. I would also say probe ordering is not a DT problem,
> > but sounds like an OS problem. Aren't there other things needing EFI
> > variables earlyish too? Do you really want to have to update the DT to
> > enable this?
> 
> I was debugging why RTC offset was not working properly for me, and
> eventually realized it was exactly this problem (efivars not avail
> when rtc probes).

Hmm. It seems dropping that property for v2 under the assumption that
efivars would be available at module init time (since the driver can
only be built-in) was a mistake.

I see now that the current qcom efivars driver does not probe until
module init time itself, but even if we change that the scm driver
depends on an interconnect driver which can be built as a module...

> Hacking up rtc-pm8xxx to return -EPROBE_DEFER "fixes" it

> > OTOH, it's one property, meh.

I guess we need that property on these platforms as I had initially
concluded after all. As with the rest of this driver, hopefully all of
this goes away for future Qualcomm platforms once they fix their UEFI
implementation so that the time service can be used directly.

Johan