From: "Michael Walle" <mwalle@kernel.org>
To: "Manikandan Muralidharan" <manikandan.m@microchip.com>,
<robh@kernel.org>, <krzk+dt@kernel.org>, <conor+dt@kernel.org>,
<nicolas.ferre@microchip.com>, <alexandre.belloni@bootlin.com>,
<claudiu.beznea@tuxon.dev>, <tudor.ambarus@linaro.org>,
<pratyush@kernel.org>, <miquel.raynal@bootlin.com>,
<richard@nod.at>, <vigneshr@ti.com>, <devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>
Cc: "Varshini Rajendran" <varshini.rajendran@microchip.com>
Subject: Re: [PATCH 1/2] mtd: spi-nor: sst: register SFDP region into NVMEM framework to read MAC Address
Date: Wed, 05 Mar 2025 11:24:47 +0100 [thread overview]
Message-ID: <D889CRJC6W19.2LDQCDVG7BLNG@kernel.org> (raw)
In-Reply-To: <20250305100134.1171124-1-manikandan.m@microchip.com>
On Wed Mar 5, 2025 at 11:01 AM CET, Manikandan Muralidharan wrote:
> From: Varshini Rajendran <varshini.rajendran@microchip.com>
>
> EUI identifier and the MAC Address of the Ethernet Interface is stored
> after the SFDP table of contents starting at address 0x260 in the
> QSPI memory.
> Register the entire SFDP region read by the spi-nor (nor->sfdp) into the
> NVMEM framework and read the MAC Address when requested using the nvmem
> properties in the DT by the net drivers.
>
> In kernel the Ethernet MAC address relied on U-Boot env variables or
> generated a random address, which posed challenges for boards without
> on-board EEPROMs or with multiple Ethernet ports.
> This change ensures consistent and reliable MAC address retrieval from QSPI,
> benefiting boards like the sama5d29 curiosity and sam9x75 curiosity.
>
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> [manikandan.m@microchip.com: Integrate the nvmem->read callback framework]
> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
> ---
> drivers/mtd/spi-nor/sst.c | 62 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
> index 175211fe6a5e..a0abf201ad41 100644
> --- a/drivers/mtd/spi-nor/sst.c
> +++ b/drivers/mtd/spi-nor/sst.c
> @@ -5,6 +5,7 @@
> */
>
> #include <linux/mtd/spi-nor.h>
> +#include <linux/nvmem-provider.h>
>
> #include "core.h"
>
> @@ -13,6 +14,8 @@
>
> #define SST26VF_CR_BPNV BIT(3)
>
> +#define SST26VF_SFDP_EUI48 0x30
> +
> static int sst26vf_nor_lock(struct spi_nor *nor, loff_t ofs, u64 len)
> {
> return -EOPNOTSUPP;
> @@ -56,8 +59,67 @@ static int sst26vf_nor_late_init(struct spi_nor *nor)
> return 0;
> }
>
> +/**
> + * sst26vf_sfdp_mac_addr_read() - check if the EUI-48 MAC Address is programmed
> + * and read the data from the prestored SFDP data
> + *
> + * @priv: User context passed to read callbacks.
> + * @offset: Offset within the NVMEM device.
> + * @val: pointer where to fill the ethernet address
> + * @bytes: Length of the NVMEM cell
> + *
> + * Return: 0 on success, -EINVAL otherwise.
> + */
> +static int sst26vf_sfdp_mac_addr_read(void *priv, unsigned int off,
> + void *val, size_t bytes)
> +{
> + struct spi_nor *nor = priv;
> + struct sfdp *sfdp = nor->sfdp;
> + loff_t offset = off;
> + size_t sfdp_size;
> +
> + /*
> + * Check if the EUI-48 MAC address is programmed in the next six address
> + * locations.
> + * @off is programmed in the DT and stores the start of MAC Address
> + * byte, (off - 1) stores the bit length of the Extended Unique
> + * Identifier
> + */
> + if (SST26VF_SFDP_EUI48 != *((u8 *)sfdp->dwords + (offset - 1)))
> + return -EINVAL;
What happens if you read at a different offset? You're exposing
the entire SFDP region. What happens if there is a 0x30 at a
different location?
> +
> + sfdp_size = sfdp->num_dwords * sizeof(*sfdp->dwords);
> + memory_read_from_buffer(val, bytes, &offset, sfdp->dwords,
> + sfdp_size);
> + return 0;
> +}
> +
> +static struct nvmem_config sst26vf_sfdp_nvmem_config = {
> + .word_size = 1,
> + .stride = 1,
> +};
> +
> +static int sst26vf_nor_post_sfdp(struct spi_nor *nor)
> +{
> + struct nvmem_device *nvmem;
> +
> + sst26vf_sfdp_nvmem_config.dev = nor->dev;
> + sst26vf_sfdp_nvmem_config.size = nor->sfdp->num_dwords * sizeof(*nor->sfdp->dwords);
> + sst26vf_sfdp_nvmem_config.priv = nor;
> + sst26vf_sfdp_nvmem_config.reg_read = sst26vf_sfdp_mac_addr_read;
> +
> + nvmem = devm_nvmem_register(nor->dev, &sst26vf_sfdp_nvmem_config);
> + if (IS_ERR(nvmem)) {
> + dev_err(nor->dev, "failed to register NVMEM device: %ld\n", PTR_ERR(nvmem));
> + return PTR_ERR(nvmem);
I don't think it makes sense to have this one-off in a particular
driver. If at all, this should be handled in the core. Sorry, but
this really looks like an ugly hack.
-michael
> + }
> +
> + return 0;
> +}
> +
> static const struct spi_nor_fixups sst26vf_nor_fixups = {
> .late_init = sst26vf_nor_late_init,
> + .post_sfdp = sst26vf_nor_post_sfdp,
> };
>
> static const struct flash_info sst_nor_parts[] = {
WARNING: multiple messages have this Message-ID (diff)
From: "Michael Walle" <mwalle@kernel.org>
To: "Manikandan Muralidharan" <manikandan.m@microchip.com>,
<robh@kernel.org>, <krzk+dt@kernel.org>, <conor+dt@kernel.org>,
<nicolas.ferre@microchip.com>, <alexandre.belloni@bootlin.com>,
<claudiu.beznea@tuxon.dev>, <tudor.ambarus@linaro.org>,
<pratyush@kernel.org>, <miquel.raynal@bootlin.com>,
<richard@nod.at>, <vigneshr@ti.com>, <devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>
Cc: "Varshini Rajendran" <varshini.rajendran@microchip.com>
Subject: Re: [PATCH 1/2] mtd: spi-nor: sst: register SFDP region into NVMEM framework to read MAC Address
Date: Wed, 05 Mar 2025 11:24:47 +0100 [thread overview]
Message-ID: <D889CRJC6W19.2LDQCDVG7BLNG@kernel.org> (raw)
In-Reply-To: <20250305100134.1171124-1-manikandan.m@microchip.com>
On Wed Mar 5, 2025 at 11:01 AM CET, Manikandan Muralidharan wrote:
> From: Varshini Rajendran <varshini.rajendran@microchip.com>
>
> EUI identifier and the MAC Address of the Ethernet Interface is stored
> after the SFDP table of contents starting at address 0x260 in the
> QSPI memory.
> Register the entire SFDP region read by the spi-nor (nor->sfdp) into the
> NVMEM framework and read the MAC Address when requested using the nvmem
> properties in the DT by the net drivers.
>
> In kernel the Ethernet MAC address relied on U-Boot env variables or
> generated a random address, which posed challenges for boards without
> on-board EEPROMs or with multiple Ethernet ports.
> This change ensures consistent and reliable MAC address retrieval from QSPI,
> benefiting boards like the sama5d29 curiosity and sam9x75 curiosity.
>
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> [manikandan.m@microchip.com: Integrate the nvmem->read callback framework]
> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
> ---
> drivers/mtd/spi-nor/sst.c | 62 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
> index 175211fe6a5e..a0abf201ad41 100644
> --- a/drivers/mtd/spi-nor/sst.c
> +++ b/drivers/mtd/spi-nor/sst.c
> @@ -5,6 +5,7 @@
> */
>
> #include <linux/mtd/spi-nor.h>
> +#include <linux/nvmem-provider.h>
>
> #include "core.h"
>
> @@ -13,6 +14,8 @@
>
> #define SST26VF_CR_BPNV BIT(3)
>
> +#define SST26VF_SFDP_EUI48 0x30
> +
> static int sst26vf_nor_lock(struct spi_nor *nor, loff_t ofs, u64 len)
> {
> return -EOPNOTSUPP;
> @@ -56,8 +59,67 @@ static int sst26vf_nor_late_init(struct spi_nor *nor)
> return 0;
> }
>
> +/**
> + * sst26vf_sfdp_mac_addr_read() - check if the EUI-48 MAC Address is programmed
> + * and read the data from the prestored SFDP data
> + *
> + * @priv: User context passed to read callbacks.
> + * @offset: Offset within the NVMEM device.
> + * @val: pointer where to fill the ethernet address
> + * @bytes: Length of the NVMEM cell
> + *
> + * Return: 0 on success, -EINVAL otherwise.
> + */
> +static int sst26vf_sfdp_mac_addr_read(void *priv, unsigned int off,
> + void *val, size_t bytes)
> +{
> + struct spi_nor *nor = priv;
> + struct sfdp *sfdp = nor->sfdp;
> + loff_t offset = off;
> + size_t sfdp_size;
> +
> + /*
> + * Check if the EUI-48 MAC address is programmed in the next six address
> + * locations.
> + * @off is programmed in the DT and stores the start of MAC Address
> + * byte, (off - 1) stores the bit length of the Extended Unique
> + * Identifier
> + */
> + if (SST26VF_SFDP_EUI48 != *((u8 *)sfdp->dwords + (offset - 1)))
> + return -EINVAL;
What happens if you read at a different offset? You're exposing
the entire SFDP region. What happens if there is a 0x30 at a
different location?
> +
> + sfdp_size = sfdp->num_dwords * sizeof(*sfdp->dwords);
> + memory_read_from_buffer(val, bytes, &offset, sfdp->dwords,
> + sfdp_size);
> + return 0;
> +}
> +
> +static struct nvmem_config sst26vf_sfdp_nvmem_config = {
> + .word_size = 1,
> + .stride = 1,
> +};
> +
> +static int sst26vf_nor_post_sfdp(struct spi_nor *nor)
> +{
> + struct nvmem_device *nvmem;
> +
> + sst26vf_sfdp_nvmem_config.dev = nor->dev;
> + sst26vf_sfdp_nvmem_config.size = nor->sfdp->num_dwords * sizeof(*nor->sfdp->dwords);
> + sst26vf_sfdp_nvmem_config.priv = nor;
> + sst26vf_sfdp_nvmem_config.reg_read = sst26vf_sfdp_mac_addr_read;
> +
> + nvmem = devm_nvmem_register(nor->dev, &sst26vf_sfdp_nvmem_config);
> + if (IS_ERR(nvmem)) {
> + dev_err(nor->dev, "failed to register NVMEM device: %ld\n", PTR_ERR(nvmem));
> + return PTR_ERR(nvmem);
I don't think it makes sense to have this one-off in a particular
driver. If at all, this should be handled in the core. Sorry, but
this really looks like an ugly hack.
-michael
> + }
> +
> + return 0;
> +}
> +
> static const struct spi_nor_fixups sst26vf_nor_fixups = {
> .late_init = sst26vf_nor_late_init,
> + .post_sfdp = sst26vf_nor_post_sfdp,
> };
>
> static const struct flash_info sst_nor_parts[] = {
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2025-03-05 10:59 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 10:01 [PATCH 1/2] mtd: spi-nor: sst: register SFDP region into NVMEM framework to read MAC Address Manikandan Muralidharan
2025-03-05 10:01 ` Manikandan Muralidharan
2025-03-05 10:01 ` [PATCH 2/2] ARM: dts: microchip: sama5d29_curiosity: Add nvmem-layout in QSPI to describe EUI48 MAC address region Manikandan Muralidharan
2025-03-05 10:01 ` Manikandan Muralidharan
2025-03-05 10:31 ` Michael Walle
2025-03-05 10:31 ` Michael Walle
2025-03-05 10:22 ` [PATCH 1/2] mtd: spi-nor: sst: register SFDP region into NVMEM framework to read MAC Address Miquel Raynal
2025-03-05 10:22 ` Miquel Raynal
2025-03-05 10:22 ` Miquel Raynal
2025-03-06 6:40 ` Manikandan.M
2025-03-06 7:41 ` Michael Walle
2025-03-06 7:41 ` Michael Walle
2025-03-06 7:41 ` Michael Walle
2025-03-06 10:33 ` Manikandan.M
2025-03-05 10:24 ` Michael Walle [this message]
2025-03-05 10:24 ` Michael Walle
2025-03-06 7:09 ` Manikandan.M
2025-03-06 8:34 ` Miquel Raynal
2025-03-06 8:34 ` Miquel Raynal
2025-03-06 8:34 ` Miquel Raynal
2025-03-06 8:39 ` Michael Walle
2025-03-06 8:39 ` Michael Walle
2025-03-06 8:39 ` Michael Walle
2025-03-06 8:56 ` Miquel Raynal
2025-03-06 8:56 ` Miquel Raynal
2025-03-06 8:56 ` Miquel Raynal
2025-03-05 15:09 ` Rob Herring (Arm)
2025-03-05 15:09 ` Rob Herring (Arm)
2025-03-05 15:09 ` Rob Herring (Arm)
2025-03-06 4:24 ` kernel test robot
2025-03-06 4:24 ` kernel test robot
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=D889CRJC6W19.2LDQCDVG7BLNG@kernel.org \
--to=mwalle@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=claudiu.beznea@tuxon.dev \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=manikandan.m@microchip.com \
--cc=miquel.raynal@bootlin.com \
--cc=nicolas.ferre@microchip.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=tudor.ambarus@linaro.org \
--cc=varshini.rajendran@microchip.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.