From: "Michael Walle" <mwalle@kernel.org>
To: "Manikandan Muralidharan" <manikandan.m@microchip.com>,
<pratyush@kernel.org>, <mwalle@kernel.org>,
<takahiro.kuwano@infineon.com>, <miquel.raynal@bootlin.com>,
<richard@nod.at>, <vigneshr@ti.com>, <robh@kernel.org>,
<krzk+dt@kernel.org>, <conor+dt@kernel.org>, <srini@kernel.org>,
<nicolas.ferre@microchip.com>, <alexandre.belloni@bootlin.com>,
<claudiu.beznea@tuxon.dev>, <linux@armlinux.org.uk>,
<richardcochran@gmail.com>, <arnd@arndb.de>, <linusw@kernel.org>,
<linux-mtd@lists.infradead.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH v6 3/7] mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device
Date: Wed, 29 Jul 2026 10:01:59 +0200 [thread overview]
Message-ID: <DKAWBT1F1VM2.1LA8AKQ6B17AE@kernel.org> (raw)
In-Reply-To: <20260729043026.1811147-4-manikandan.m@microchip.com>
[-- Attachment #1.1: Type: text/plain, Size: 2429 bytes --]
On Wed Jul 29, 2026 at 6:30 AM CEST, Manikandan Muralidharan wrote:
..
> +static void spi_nor_sfdp_nvmem_put_np(void *data)
> +{
> + of_node_put(data);
> +}
> +
> +/**
> + * spi_nor_register_sfdp_nvmem() - expose the SFDP as a read-only NVMEM device
> + * @nor: pointer to a 'struct spi_nor'
> + *
> + * Expose the whole SFDP, in on-flash byte order, as a read-only NVMEM device
> + * rooted at the flash's SFDP child node (compatible "jedec,sfdp"). This lets
> + * generic (fixed-layout) or vendor (nvmem-layout) cells reference any SFDP
> + * data. The device is only registered when a child node with the "jedec,sfdp"
> + * compatible is described in the device tree.
> + *
> + * Return: 0 on success or if there is nothing to do, -errno otherwise.
> + */
> +static int spi_nor_register_sfdp_nvmem(struct spi_nor *nor)
> +{
> + struct device *dev = nor->dev;
> + struct nvmem_config config = { };
> + struct nvmem_device *nvmem;
> + struct device_node *np;
> + int ret;
> +
> + if (!nor->sfdp)
> + return 0;
> +
> + np = of_get_compatible_child(dev_of_node(dev), "jedec,sfdp");
> + if (!np)
> + return 0;
> +
> + /*
> + * Register the put before devm_nvmem_register() so it runs last on
> + * detach, after the NVMEM device that uses the node is gone.
> + */
> + ret = devm_add_action_or_reset(dev, spi_nor_sfdp_nvmem_put_np, np);
> + if (ret)
> + return ret;
Sorry I've missed that in the previous version. I guess we do that
because we hand the device_node to nvmem. But shouldn't it be part
of the NVMEM framework to do a of_node_get()?
> +
> + config.dev = dev;
> + config.of_node = np;
> + config.name = "sfdp";
> + config.id = NVMEM_DEVID_AUTO;
> + config.owner = THIS_MODULE;
> + config.read_only = true;
> + config.word_size = 1;
> + config.stride = 1;
> + config.size = (int)(nor->sfdp->num_dwords * sizeof(*nor->sfdp->dwords));
> + config.reg_read = spi_nor_sfdp_reg_read;
> + config.priv = nor;
> +
> + nvmem = devm_nvmem_register(dev, &config);
> + if (IS_ERR(nvmem)) {
> + /* NVMEM support is optional. */
> + if (PTR_ERR(nvmem) == -EOPNOTSUPP)
> + return 0;
> + return dev_err_probe(dev, PTR_ERR(nvmem),
> + "failed to register SFDP NVMEM device\n");
> + }
> +
so we can do a of_node_put() here?
-michael
> + dev_dbg(dev, "exposed %d-byte SFDP as an NVMEM device\n", config.size);
> +
> + return 0;
> +}
> +
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: "Michael Walle" <mwalle@kernel.org>
To: "Manikandan Muralidharan" <manikandan.m@microchip.com>,
<pratyush@kernel.org>, <mwalle@kernel.org>,
<takahiro.kuwano@infineon.com>, <miquel.raynal@bootlin.com>,
<richard@nod.at>, <vigneshr@ti.com>, <robh@kernel.org>,
<krzk+dt@kernel.org>, <conor+dt@kernel.org>, <srini@kernel.org>,
<nicolas.ferre@microchip.com>, <alexandre.belloni@bootlin.com>,
<claudiu.beznea@tuxon.dev>, <linux@armlinux.org.uk>,
<richardcochran@gmail.com>, <arnd@arndb.de>, <linusw@kernel.org>,
<linux-mtd@lists.infradead.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH v6 3/7] mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device
Date: Wed, 29 Jul 2026 10:01:59 +0200 [thread overview]
Message-ID: <DKAWBT1F1VM2.1LA8AKQ6B17AE@kernel.org> (raw)
In-Reply-To: <20260729043026.1811147-4-manikandan.m@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]
On Wed Jul 29, 2026 at 6:30 AM CEST, Manikandan Muralidharan wrote:
..
> +static void spi_nor_sfdp_nvmem_put_np(void *data)
> +{
> + of_node_put(data);
> +}
> +
> +/**
> + * spi_nor_register_sfdp_nvmem() - expose the SFDP as a read-only NVMEM device
> + * @nor: pointer to a 'struct spi_nor'
> + *
> + * Expose the whole SFDP, in on-flash byte order, as a read-only NVMEM device
> + * rooted at the flash's SFDP child node (compatible "jedec,sfdp"). This lets
> + * generic (fixed-layout) or vendor (nvmem-layout) cells reference any SFDP
> + * data. The device is only registered when a child node with the "jedec,sfdp"
> + * compatible is described in the device tree.
> + *
> + * Return: 0 on success or if there is nothing to do, -errno otherwise.
> + */
> +static int spi_nor_register_sfdp_nvmem(struct spi_nor *nor)
> +{
> + struct device *dev = nor->dev;
> + struct nvmem_config config = { };
> + struct nvmem_device *nvmem;
> + struct device_node *np;
> + int ret;
> +
> + if (!nor->sfdp)
> + return 0;
> +
> + np = of_get_compatible_child(dev_of_node(dev), "jedec,sfdp");
> + if (!np)
> + return 0;
> +
> + /*
> + * Register the put before devm_nvmem_register() so it runs last on
> + * detach, after the NVMEM device that uses the node is gone.
> + */
> + ret = devm_add_action_or_reset(dev, spi_nor_sfdp_nvmem_put_np, np);
> + if (ret)
> + return ret;
Sorry I've missed that in the previous version. I guess we do that
because we hand the device_node to nvmem. But shouldn't it be part
of the NVMEM framework to do a of_node_get()?
> +
> + config.dev = dev;
> + config.of_node = np;
> + config.name = "sfdp";
> + config.id = NVMEM_DEVID_AUTO;
> + config.owner = THIS_MODULE;
> + config.read_only = true;
> + config.word_size = 1;
> + config.stride = 1;
> + config.size = (int)(nor->sfdp->num_dwords * sizeof(*nor->sfdp->dwords));
> + config.reg_read = spi_nor_sfdp_reg_read;
> + config.priv = nor;
> +
> + nvmem = devm_nvmem_register(dev, &config);
> + if (IS_ERR(nvmem)) {
> + /* NVMEM support is optional. */
> + if (PTR_ERR(nvmem) == -EOPNOTSUPP)
> + return 0;
> + return dev_err_probe(dev, PTR_ERR(nvmem),
> + "failed to register SFDP NVMEM device\n");
> + }
> +
so we can do a of_node_put() here?
-michael
> + dev_dbg(dev, "exposed %d-byte SFDP as an NVMEM device\n", config.size);
> +
> + return 0;
> +}
> +
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
next prev parent reply other threads:[~2026-07-29 8:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 4:30 [PATCH v6 0/7] Read MAC address from SST vendor specific SFDP region Manikandan Muralidharan
2026-07-29 4:30 ` Manikandan Muralidharan
2026-07-29 4:30 ` [PATCH v6 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM Manikandan Muralidharan
2026-07-29 4:30 ` Manikandan Muralidharan
2026-07-29 4:30 ` [PATCH v6 2/7] dt-bindings: nvmem: layouts: add Microchip/SST SFDP EUI layout Manikandan Muralidharan
2026-07-29 4:30 ` Manikandan Muralidharan
2026-07-29 4:30 ` [PATCH v6 3/7] mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device Manikandan Muralidharan
2026-07-29 4:30 ` Manikandan Muralidharan
2026-07-29 8:01 ` Michael Walle [this message]
2026-07-29 8:01 ` Michael Walle
2026-07-29 9:08 ` Manikandan.M
2026-07-29 9:08 ` Manikandan.M
2026-07-29 4:30 ` [PATCH v6 4/7] nvmem: layouts: add Microchip/SST SFDP EUI layout driver Manikandan Muralidharan
2026-07-29 4:30 ` Manikandan Muralidharan
2026-07-29 4:30 ` [PATCH v6 5/7] ARM: dts: microchip: sama5d27_wlsom1: use fixed-partitions for QSPI flash Manikandan Muralidharan
2026-07-29 4:30 ` Manikandan Muralidharan
2026-07-29 4:30 ` [PATCH v6 6/7] ARM: dts: microchip: sama5d27_wlsom1: read MAC address from QSPI SFDP Manikandan Muralidharan
2026-07-29 4:30 ` Manikandan Muralidharan
2026-07-29 4:30 ` [PATCH v6 7/7] ARM: configs: sama5: enable Microchip/SST SFDP EUI NVMEM layout Manikandan Muralidharan
2026-07-29 4:30 ` Manikandan Muralidharan
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=DKAWBT1F1VM2.1LA8AKQ6B17AE@kernel.org \
--to=mwalle@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=arnd@arndb.de \
--cc=claudiu.beznea@tuxon.dev \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=manikandan.m@microchip.com \
--cc=miquel.raynal@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
--cc=srini@kernel.org \
--cc=takahiro.kuwano@infineon.com \
--cc=vigneshr@ti.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.