[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aFloifxONXnQbVg6@hovoldconsulting.com>
Date: Mon, 23 Jun 2025 16:45:29 +0200
From: Johan Hovold <johan@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: 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 Sat, Jun 21, 2025 at 10:56:11PM +0300, Dmitry Baryshkov wrote:
> For some platforms (e.g. Lenovo Yoga C630) we don't yet know a way to
> update variables in the permanent storage. However being able to read
> the vars is still useful as it allows us to get e.g. RTC offset.
>
> Add a quirk for QSEECOM specifying that UEFI variables for this platform
> should be registered in read-only mode.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
> ---
> drivers/firmware/qcom/qcom_qseecom_uefisecapp.c | 18 +++++++++++++++++-
> include/linux/firmware/qcom/qcom_qseecom.h | 2 ++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c b/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c
> index 98a463e9774bf04f2deb0f7fa1318bd0d2edfa49..05f700dcb8cf3189f640237ff0e045564abb8264 100644
> --- a/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c
> +++ b/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c
> @@ -792,6 +792,12 @@ static efi_status_t qcuefi_query_variable_info(u32 attr, u64 *storage_space, u64
> return status;
> }
>
> +static const struct efivar_operations qcom_efivars_ro_ops = {
> + .get_variable = qcuefi_get_variable,
> + .get_next_variable = qcuefi_get_next_variable,
> + .query_variable_info = qcuefi_query_variable_info,
> +};
It looks like the efivars implementation does not support read-only
efivars and this will lead to NULL pointer dereferences whenever you try
to write a variable.
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?
Johan
Powered by blists - more mailing lists