Re: [PATCH v2 2/4] firmware: qcom: uefisecapp: add support for R/O UEFI vars

[Johan Hovold <johan@kernel.org>]

On Thu, Jun 26, 2025 at 02:15:26PM +0300, Dmitry Baryshkov wrote:
> On Thu, Jun 26, 2025 at 11:42:50AM +0200, Johan Hovold wrote:
> > On Tue, Jun 24, 2025 at 04:13:34AM +0300, Dmitry Baryshkov wrote:
> > > On Mon, Jun 23, 2025 at 04:50:27PM +0200, Johan Hovold wrote:
> > > > On Mon, Jun 23, 2025 at 04:45:30PM +0200, Johan Hovold wrote:
> > 
> > > > > Also not sure how useful it is to only be able to read variables,
> > > > > including for the RTC where you'll end up with an RTC that's always
> > > > > slightly off due to drift (even if you can set it when booting into
> > > > > Windows or possibly from the UEFI setup).
> > > > > 
> > > > > Don't you have any SDAM blocks in the PMICs that you can use instead for
> > > > > a proper functioning RTC on these machines?
> > > 
> > > I'd rather not poke into an SDAM, especially since we don't have docs
> > > which SDAM blocks are used and which are not.
> > 
> > You're with Qualcomm now so you should be able to dig up this
> > information like we did for the X13s (even if I'm quite aware that it
> > may still be easier said than done).
> 
> I'd rather try to find information on how to update UEFI vars on the
> storage.

You can do both, especially if it turns out you won't be able to have
persistent variables on these machines.

> Moreover, using the UEFI variable doesn't send the wrong
> message to other developers (if I remember correctly, I've seen patches
> poking to semi-random SDAM just because it seemed to be unused).

That's for the Qualcomm maintainers, and the rest of us, to catch during
review. And people putting random values into devicetrees is
unfortunately not limited to SDAM addresses.

Furthermore, getting an allocated block of addresses in SDAM for Linux
could be useful for other things too.
 
> > > I think the slightly drifted RTC is still much better than ending up
> > > with an RTC value which is significantly off, because it was set via the
> > > file modification time.
> > 
> > I measured drift of 1 second every 3.5 h on the X13s, so having an
> > almost correct time with massive drift that cannot be corrected for may
> > not necessarily be better.
> 
> For me it provided a better user experience. Yes, I'm using C630 from
> time to time, including the kernel development. A drifted but ticking
> RTC is better than the RTC that rolls backs by several months at a
> reboot, because of the missing RTC offset info.

Does it have to roll back? Can't you just keep it running after whatever
semi-random date it started at? And there is ntp and services like
fake-hwclock which saves the time on shutdown too.

Anyway, I still do no understand why you seem so reluctant to having a
proper functioning RTC using an SDAM offset.

Johan