[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aF1UIcrNC5PULiqg@hovoldconsulting.com>
Date: Thu, 26 Jun 2025 16:07:29 +0200
From: Johan Hovold <johan@...nel.org>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Bjorn Andersson <andersson@...nel.org>,
Maximilian Luz <luzmaximilian@...il.com>,
Konrad Dybcio <konradybcio@...nel.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/4] firmware: qcom: uefisecapp: add support for R/O
UEFI vars
On Thu, Jun 26, 2025 at 03:49:32PM +0200, Konrad Dybcio wrote:
> On 6/26/25 3:13 PM, Johan Hovold wrote:
> > 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.
>
> The danger here is that we only know what Qualcomm uses these cells
> for, not necessarily what the vendors with a similar idea could
> have come up with.
Hmm. Good point.
But at least the address we used on sc8280xp appears to be cleared on
hard reset (holding down the power button) so it can't be used for
anything that useful it seems.
> This is especially important since (unfortunately without going into
> detail), you *really* don't want to mess up some existing values in
> there.
Yeah, I wouldn't pick a random address without getting an ack from
Qualcomm first.
Johan
Powered by blists - more mailing lists