From: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
To: Abel Vesa <abel.vesa@oss.qualcomm.com>
Cc: Srinivas Kandagatla <srini@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Marcel Holtmann <marcel@holtmann.org>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
Jeff Johnson <jjohnson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Abel Vesa <abelvesa@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-wireless@vger.kernel.org, ath12k@lists.infradead.org
Subject: Re: [PATCH RFC 2/5] nvmem: Add UEFI variable NVMEM provider
Date: Thu, 15 Oct 2026 08:29:15 +0200 [thread overview]
Message-ID: <atBwaKE20dJF1jXP@monoceros> (raw)
In-Reply-To: <20261014-b4-nvmem-efivar-v1-2-187c85f65018@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 4966 bytes --]
On Wed, Oct 14, 2026 at 04:02:40PM +0300, Abel Vesa wrote:
> +#include <linux/mod_devicetable.h>
> [...]
> +#include <linux/platform_device.h>
<linux/mod_devicetable.h> pulls in a lot of unneeded dependencies and
<linux/platform_device.h> already provides of_device_id. So please drop
the former.
> +static int efivar_nvmem_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + const char *name, *guid_str;
> + struct nvmem_config cfg = {};
> + struct efivar_nvmem *priv;
> + struct nvmem_device *nvmem;
> + efi_char16_t *name16;
> + efi_guid_t guid;
> + guid_t g;
> + unsigned long size;
> + efi_status_t status;
> + u32 attr;
> + int i, len, ret;
> + void *buf;
> +
> + /*
> + * The EFI variable service may not be a native EFI runtime service;
> + * backends such as the Qualcomm uefisecapp driver register the
> + * efivars operations asynchronously. Wait for them.
> + */
> + if (!efivar_is_available())
> + return -EPROBE_DEFER;
> +
> + ret = device_property_read_string(dev, "efivar-name", &name);
> + if (ret)
> + return dev_err_probe(dev, ret, "missing 'efivar-name'\n");
> +
> + /* ASCII variable name -> UCS-2 as expected by the EFI service */
> + len = strlen(name);
> + name16 = kcalloc(len + 1, sizeof(*name16), GFP_KERNEL);
> + if (!name16)
> + return -ENOMEM;
> + for (i = 0; i < len; i++)
> + name16[i] = name[i];
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv) {
> + kfree(name16);
> + return -ENOMEM;
> + }
> +
> + /*
> + * The vendor GUID is optional: if it is not provided, look the
> + * variable up by name across the whole store. A variable that has
> + * not been provisioned yet is reported as not found and handled
> + * below like an erased EEPROM.
> + */
> + if (!device_property_read_string(dev, "efivar-guid", &guid_str)) {
> + ret = guid_parse(guid_str, &g);
> + if (ret) {
> + kfree(name16);
> + return dev_err_probe(dev, ret, "invalid 'efivar-guid'\n");
> + }
> + memcpy(&guid, &g, sizeof(guid));
> + status = EFI_SUCCESS;
> + } else {
> + ret = efivar_nvmem_find_guid(name16, &guid);
> + if (ret && ret != -ENODEV) {
> + kfree(name16);
> + return dev_err_probe(dev, ret,
> + "failed to look up variable '%s'\n",
> + name);
> + }
> + status = ret ? EFI_NOT_FOUND : EFI_SUCCESS;
> + }
> +
> + /* First attempt with a modest buffer; grow if the firmware asks. */
> + size = 512;
> + buf = kzalloc(size, GFP_KERNEL);
> + if (!buf) {
> + kfree(name16);
> + return -ENOMEM;
> + }
> +
> + if (status == EFI_SUCCESS) {
> + status = efivar_get_variable(name16, &guid, &attr, &size, buf);
> + if (status == EFI_BUFFER_TOO_SMALL) {
> + kfree(buf);
> + buf = kzalloc(size, GFP_KERNEL);
> + if (!buf) {
> + kfree(name16);
> + return -ENOMEM;
> + }
> + status = efivar_get_variable(name16, &guid, &attr,
> + &size, buf);
> + }
> + }
> + kfree(name16);
> +
> + if (status == EFI_NOT_FOUND) {
> + /*
> + * Variable not provisioned yet: behave like an erased
> + * EEPROM so that consumers still probe and fall back to
> + * their defaults.
> + */
> + kfree(buf);
> + size = efivar_nvmem_cells_extent(dev);
> + if (!size)
> + return dev_err_probe(dev, -ENODEV,
> + "variable '%s' not found and no cells described\n",
> + name);
> + buf = kzalloc(size, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> + dev_info(dev, "variable '%s' not provisioned, reading as zeroes\n",
> + name);
> + } else if (status != EFI_SUCCESS) {
> + kfree(buf);
> + return dev_err_probe(dev, -ENODEV,
> + "GetVariable('%s') failed: 0x%lx\n",
> + name, status);
> + } else {
> + dev_dbg(dev, "variable '%s' attr=0x%x size=%lu\n",
> + name, attr, size);
> + }
> +
> + priv->data = devm_kmemdup(dev, buf, size, GFP_KERNEL);
> + kfree(buf);
> + if (!priv->data)
> + return -ENOMEM;
> + priv->size = size;
> +
> + cfg.dev = dev;
> + cfg.name = "efivar";
> + cfg.id = NVMEM_DEVID_AUTO;
> + cfg.owner = THIS_MODULE;
> + cfg.type = NVMEM_TYPE_OTP;
> + cfg.read_only = true;
> + cfg.word_size = 1;
> + cfg.stride = 1;
> + cfg.size = priv->size;
> + cfg.reg_read = efivar_nvmem_reg_read;
> + cfg.priv = priv;
> + cfg.of_node = dev->of_node;
> + cfg.add_legacy_fixed_of_cells = true;
having only nearly all of these aligned is really strange. If you ask
me, don't try to align =, just use a single space before it.
You can write this as:
cfg = (typeof(cfg)) {
.dev = dev,
.name = "efivar",
...
};
which is a bit less repetitive and easier for the compiler to optimize.
> + nvmem = devm_nvmem_register(dev, &cfg);
Does nvmem_register only return success or -ENOMEM? If not, a
dev_err_probe() would be nice here.
> + return PTR_ERR_OR_ZERO(nvmem);
> +}
> +
> +static const struct of_device_id efivar_nvmem_of_match[] = {
> + { .compatible = "nvmem-efivar" },
> + {}
s/{}/{ }/
> +};
> +MODULE_DEVICE_TABLE(of, efivar_nvmem_of_match);
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-10-15 6:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 13:02 [PATCH RFC 0/5] nvmem: Add a UEFI variable backed " Abel Vesa
2026-10-14 13:02 ` [PATCH RFC 1/5] dt-bindings: nvmem: Add UEFI variable " Abel Vesa
2026-10-14 13:02 ` [PATCH RFC 2/5] " Abel Vesa
2026-10-15 6:29 ` Uwe Kleine-König [this message]
2026-10-15 13:22 ` Bartosz Golaszewski
2026-10-15 21:41 ` Jeff Johnson
2026-10-14 13:02 ` [PATCH RFC 3/5] Bluetooth: hci_qca: Support BD address from an nvmem cell Abel Vesa
2026-10-14 13:02 ` [PATCH RFC 4/5] wifi: ath12k: Support MAC address from the firmware node Abel Vesa
2026-10-15 6:18 ` Paul Menzel
2026-10-14 13:02 ` [PATCH RFC 5/5] arm64: dts: qcom: glymur-crd: Source MAC addresses from a UEFI variable Abel Vesa
2026-10-14 14:05 ` Konrad Dybcio
2026-10-15 13:22 ` Bartosz Golaszewski
2026-10-14 14:05 ` [PATCH RFC 0/5] nvmem: Add a UEFI variable backed NVMEM provider Konrad Dybcio
2026-10-15 16:27 ` Stephan Gerhold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atBwaKE20dJF1jXP@monoceros \
--to=u.kleine-koenig@baylibre.com \
--cc=abel.vesa@oss.qualcomm.com \
--cc=abelvesa@kernel.org \
--cc=andersson@kernel.org \
--cc=ath12k@lists.infradead.org \
--cc=brgl@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=jjohnson@kernel.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=robh@kernel.org \
--cc=srini@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®