[PATCH 0/2] qnap-mcu: add nvmem subdevice to read the eeprom

[PATCH 0/2] qnap-mcu: add nvmem subdevice to read the eeprom

[Heiko Stuebner]

The qnap-mcu is firmware running on a Weltrend WT61P803 MCU and there is
an eeprom connected to it, that can be read via the serial interface.

The eeprom is somewhat important, as it contains for example the
assigned mac address for the rk3568's gmac interface on TSx33 devices.

So add a nvmem driver for it and hook it into the mfd.

Heiko Stuebner (2):
  dt-bindings: mfd: qnap,ts433-mcu: allow nvmem-layout child node
  nvmem: add driver for the eeprom in qnap-mcu controllers

 .../bindings/mfd/qnap,ts433-mcu.yaml          |   3 +
 drivers/mfd/qnap-mcu.c                        |   1 +
 drivers/nvmem/Kconfig                         |   9 ++
 drivers/nvmem/Makefile                        |   2 +
 drivers/nvmem/qnap-mcu-eeprom.c               | 110 ++++++++++++++++++
 5 files changed, 125 insertions(+)
 create mode 100644 drivers/nvmem/qnap-mcu-eeprom.c

-- 
2.47.2

[PATCH 1/2] dt-bindings: mfd: qnap,ts433-mcu: allow nvmem-layout child node

[Heiko Stuebner]

The MCU has an eeprom memory connected internally, that for example
contains some mac-addresses for the soc gmac controllers.

Therefore allow defining the nvmem-layout for the eeprom.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
 Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml b/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
index fe9e06cfb933..5454d9403cad 100644
--- a/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
+++ b/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
@@ -19,6 +19,9 @@ properties:
       - qnap,ts233-mcu
       - qnap,ts433-mcu
 
+  nvmem-layout:
+    $ref: /schemas/nvmem/layouts/nvmem-layout.yaml
+
 patternProperties:
   "^fan-[0-9]+$":
     $ref: /schemas/hwmon/fan-common.yaml#
-- 
2.47.2

Re: [PATCH 1/2] dt-bindings: mfd: qnap,ts433-mcu: allow nvmem-layout child node

[Rob Herring (Arm)]

On Wed, 30 Jul 2025 19:22:47 +0200, Heiko Stuebner wrote:
> The MCU has an eeprom memory connected internally, that for example
> contains some mac-addresses for the soc gmac controllers.
> 
> Therefore allow defining the nvmem-layout for the eeprom.
> 
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
>  Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

Re: (subset) [PATCH 1/2] dt-bindings: mfd: qnap,ts433-mcu: allow nvmem-layout child node

[Lee Jones]

On Wed, 30 Jul 2025 19:22:47 +0200, Heiko Stuebner wrote:
> The MCU has an eeprom memory connected internally, that for example
> contains some mac-addresses for the soc gmac controllers.
> 
> Therefore allow defining the nvmem-layout for the eeprom.
> 
> 

Applied, thanks!

[1/2] dt-bindings: mfd: qnap,ts433-mcu: allow nvmem-layout child node
      commit: 17edd13a0916c7c84966b4db96fe744986c3a04b

--
Lee Jones [李琼斯]

Re: (subset) [PATCH 1/2] dt-bindings: mfd: qnap,ts433-mcu: allow nvmem-layout child node

[Lee Jones]

On Thu, 31 Jul 2025, Lee Jones wrote:

> On Wed, 30 Jul 2025 19:22:47 +0200, Heiko Stuebner wrote:
> > The MCU has an eeprom memory connected internally, that for example
> > contains some mac-addresses for the soc gmac controllers.
> > 
> > Therefore allow defining the nvmem-layout for the eeprom.
> > 
> > 
> 
> Applied, thanks!
> 
> [1/2] dt-bindings: mfd: qnap,ts433-mcu: allow nvmem-layout child node
>       commit: 17edd13a0916c7c84966b4db96fe744986c3a04b

This should have been applied to the previous set.

I eventually worked out why it wasn't applying cleanly.

-- 
Lee Jones [李琼斯]

[PATCH 2/2] nvmem: add driver for the eeprom in qnap-mcu controllers

[Heiko Stuebner]

The qnap-mcu also has an eeprom connected to it, that contains some
specific product-information like the mac addresses for the network
interfaces.

Add a nvmem driver for it.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
 drivers/mfd/qnap-mcu.c          |   1 +
 drivers/nvmem/Kconfig           |   9 +++
 drivers/nvmem/Makefile          |   2 +
 drivers/nvmem/qnap-mcu-eeprom.c | 110 ++++++++++++++++++++++++++++++++
 4 files changed, 122 insertions(+)
 create mode 100644 drivers/nvmem/qnap-mcu-eeprom.c

diff --git a/drivers/mfd/qnap-mcu.c b/drivers/mfd/qnap-mcu.c
index 6ed020206e55..e942ead9e515 100644
--- a/drivers/mfd/qnap-mcu.c
+++ b/drivers/mfd/qnap-mcu.c
@@ -346,6 +346,7 @@ static const struct qnap_mcu_variant qnap_ts433_mcu = {
 };
 
 static struct mfd_cell qnap_mcu_cells[] = {
+	{ .name = "qnap-mcu-eeprom", },
 	{ .name = "qnap-mcu-input", },
 	{ .name = "qnap-mcu-leds", },
 	{ .name = "qnap-mcu-hwmon", }
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index d370b2ad11e7..b3975488a5aa 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -265,6 +265,15 @@ config NVMEM_QCOM_SEC_QFPROM
           This driver can also be built as a module. If so, the module will be called
           nvmem_sec_qfprom.
 
+config NVMEM_QNAP_MCU_EEPROM
+	tristate "QNAP MCU EEPROM Support"
+	depends on MFD_QNAP_MCU
+	help
+	  Say y here to enable support for accessing the EEPROM attached to
+	  QNAP MCU devices. This EEPROM contains additional runtime device
+	  information, like MAC addresses for ethernet devices that do not
+	  contain their own mac storage.
+
 config NVMEM_RAVE_SP_EEPROM
 	tristate "Rave SP EEPROM Support"
 	depends on RAVE_SP_CORE
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 2021d59688db..21b3ae1c57e8 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -54,6 +54,8 @@ obj-$(CONFIG_NVMEM_QCOM_QFPROM)		+= nvmem_qfprom.o
 nvmem_qfprom-y				:= qfprom.o
 obj-$(CONFIG_NVMEM_QCOM_SEC_QFPROM)	+= nvmem_sec_qfprom.o
 nvmem_sec_qfprom-y			:= sec-qfprom.o
+obj-$(CONFIG_NVMEM_QNAP_MCU_EEPROM)	+= nvmem-qnap-mcu-eeprom.o
+nvmem-qnap-mcu-eeprom-y			:= qnap-mcu-eeprom.o
 obj-$(CONFIG_NVMEM_RAVE_SP_EEPROM)	+= nvmem-rave-sp-eeprom.o
 nvmem-rave-sp-eeprom-y			:= rave-sp-eeprom.o
 obj-$(CONFIG_NVMEM_RCAR_EFUSE)		+= nvmem-rcar-efuse.o
diff --git a/drivers/nvmem/qnap-mcu-eeprom.c b/drivers/nvmem/qnap-mcu-eeprom.c
new file mode 100644
index 000000000000..fea1e7b91764
--- /dev/null
+++ b/drivers/nvmem/qnap-mcu-eeprom.c
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * ee1004 - driver for DDR4 SPD EEPROMs
+ *
+ * Copyright (C) 2017-2019 Jean Delvare
+ *
+ * Based on the at24 driver:
+ * Copyright (C) 2005-2007 David Brownell
+ * Copyright (C) 2008 Wolfram Sang, Pengutronix
+ */
+
+#include <linux/mfd/qnap-mcu.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/platform_device.h>
+
+/* Determined by trial and error until read anomalies appeared */
+#define QNAP_MCU_EEPROM_SIZE		256
+#define QNAP_MCU_EEPROM_BLOCK_SIZE	32
+
+static int qnap_mcu_eeprom_read_block(struct qnap_mcu *mcu, unsigned int offset,
+				      void *val, size_t bytes)
+{
+	const u8 cmd[] = { 0xf7, 0xa1, offset, bytes };
+	u8 *reply;
+	int ret = 0;
+
+	reply = kzalloc(bytes + sizeof(cmd), GFP_KERNEL);
+	if (!reply)
+		return -ENOMEM;
+
+	ret = qnap_mcu_exec(mcu, cmd, sizeof(cmd), reply, bytes + sizeof(cmd));
+	if (ret)
+		goto out;
+
+	/* First bytes must mirror the sent command */
+	if (memcmp(cmd, reply, sizeof(cmd))) {
+		ret = -EIO;
+		goto out;
+	}
+
+	memcpy(val, reply + sizeof(cmd), bytes);
+
+out:
+	kfree(reply);
+	return ret;
+}
+
+static int qnap_mcu_eeprom_read(void *priv, unsigned int offset, void *val, size_t bytes)
+{
+	struct qnap_mcu *mcu = priv;
+	int pos = 0, ret;
+	u8 *buf = val;
+
+	if (unlikely(!bytes))
+		return 0;
+
+	while (bytes > 0) {
+		size_t to_read = (bytes > QNAP_MCU_EEPROM_BLOCK_SIZE) ?
+						QNAP_MCU_EEPROM_BLOCK_SIZE : bytes;
+
+		ret = qnap_mcu_eeprom_read_block(mcu, offset + pos, &buf[pos], to_read);
+		if (ret < 0)
+			return ret;
+
+		pos += to_read;
+		bytes -= to_read;
+	}
+
+	return 0;
+}
+
+static int qnap_mcu_eeprom_probe(struct platform_device *pdev)
+{
+	struct qnap_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
+	struct nvmem_config nvcfg = {};
+	struct nvmem_device *ndev;
+
+	nvcfg.dev = &pdev->dev;
+	nvcfg.of_node = pdev->dev.parent->of_node;
+	nvcfg.name = dev_name(&pdev->dev);
+	nvcfg.id = NVMEM_DEVID_NONE;
+	nvcfg.owner = THIS_MODULE;
+	nvcfg.type = NVMEM_TYPE_EEPROM;
+	nvcfg.read_only = true;
+	nvcfg.root_only = false;
+	nvcfg.reg_read = qnap_mcu_eeprom_read;
+	nvcfg.size = QNAP_MCU_EEPROM_SIZE,
+	nvcfg.word_size = 1,
+	nvcfg.stride = 1,
+	nvcfg.priv = mcu,
+
+	ndev = devm_nvmem_register(&pdev->dev, &nvcfg);
+	if (IS_ERR(ndev))
+		return PTR_ERR(ndev);
+
+	return 0;
+}
+
+static struct platform_driver qnap_mcu_eeprom_driver = {
+	.probe = qnap_mcu_eeprom_probe,
+	.driver = {
+		.name = "qnap-mcu-eeprom",
+	},
+};
+module_platform_driver(qnap_mcu_eeprom_driver);
+
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_DESCRIPTION("QNAP MCU EEPROM driver");
+MODULE_LICENSE("GPL");
-- 
2.47.2

Re: [PATCH 2/2] nvmem: add driver for the eeprom in qnap-mcu controllers

[Srinivas Kandagatla]

On 7/30/25 6:22 PM, Heiko Stuebner wrote:
> The qnap-mcu also has an eeprom connected to it, that contains some
> specific product-information like the mac addresses for the network
> interfaces.
> 
> Add a nvmem driver for it.
> 
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
>  drivers/mfd/qnap-mcu.c          |   1 +
>  drivers/nvmem/Kconfig           |   9 +++
>  drivers/nvmem/Makefile          |   2 +
>  drivers/nvmem/qnap-mcu-eeprom.c | 110 ++++++++++++++++++++++++++++++++
>  4 files changed, 122 insertions(+)
>  create mode 100644 drivers/nvmem/qnap-mcu-eeprom.c
> 
In case Lee you want to take this via MFD,

Acked-by: Srinivas Kandagatla <srini@kernel.org>


--srini

> diff --git a/drivers/mfd/qnap-mcu.c b/drivers/mfd/qnap-mcu.c
> index 6ed020206e55..e942ead9e515 100644
> --- a/drivers/mfd/qnap-mcu.c
> +++ b/drivers/mfd/qnap-mcu.c
> @@ -346,6 +346,7 @@ static const struct qnap_mcu_variant qnap_ts433_mcu = {
>  };
>  
>  static struct mfd_cell qnap_mcu_cells[] = {
> +	{ .name = "qnap-mcu-eeprom", },
>  	{ .name = "qnap-mcu-input", },
>  	{ .name = "qnap-mcu-leds", },
>  	{ .name = "qnap-mcu-hwmon", }
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index d370b2ad11e7..b3975488a5aa 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -265,6 +265,15 @@ config NVMEM_QCOM_SEC_QFPROM
>            This driver can also be built as a module. If so, the module will be called
>            nvmem_sec_qfprom.
>  
> +config NVMEM_QNAP_MCU_EEPROM
> +	tristate "QNAP MCU EEPROM Support"
> +	depends on MFD_QNAP_MCU
> +	help
> +	  Say y here to enable support for accessing the EEPROM attached to
> +	  QNAP MCU devices. This EEPROM contains additional runtime device
> +	  information, like MAC addresses for ethernet devices that do not
> +	  contain their own mac storage.
> +
>  config NVMEM_RAVE_SP_EEPROM
>  	tristate "Rave SP EEPROM Support"
>  	depends on RAVE_SP_CORE
> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> index 2021d59688db..21b3ae1c57e8 100644
> --- a/drivers/nvmem/Makefile
> +++ b/drivers/nvmem/Makefile
> @@ -54,6 +54,8 @@ obj-$(CONFIG_NVMEM_QCOM_QFPROM)		+= nvmem_qfprom.o
>  nvmem_qfprom-y				:= qfprom.o
>  obj-$(CONFIG_NVMEM_QCOM_SEC_QFPROM)	+= nvmem_sec_qfprom.o
>  nvmem_sec_qfprom-y			:= sec-qfprom.o
> +obj-$(CONFIG_NVMEM_QNAP_MCU_EEPROM)	+= nvmem-qnap-mcu-eeprom.o
> +nvmem-qnap-mcu-eeprom-y			:= qnap-mcu-eeprom.o
>  obj-$(CONFIG_NVMEM_RAVE_SP_EEPROM)	+= nvmem-rave-sp-eeprom.o
>  nvmem-rave-sp-eeprom-y			:= rave-sp-eeprom.o
>  obj-$(CONFIG_NVMEM_RCAR_EFUSE)		+= nvmem-rcar-efuse.o
> diff --git a/drivers/nvmem/qnap-mcu-eeprom.c b/drivers/nvmem/qnap-mcu-eeprom.c
> new file mode 100644
> index 000000000000..fea1e7b91764
> --- /dev/null
> +++ b/drivers/nvmem/qnap-mcu-eeprom.c
> @@ -0,0 +1,110 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * ee1004 - driver for DDR4 SPD EEPROMs
> + *
> + * Copyright (C) 2017-2019 Jean Delvare
> + *
> + * Based on the at24 driver:
> + * Copyright (C) 2005-2007 David Brownell
> + * Copyright (C) 2008 Wolfram Sang, Pengutronix
> + */
> +
> +#include <linux/mfd/qnap-mcu.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-provider.h>
> +#include <linux/platform_device.h>
> +
> +/* Determined by trial and error until read anomalies appeared */
> +#define QNAP_MCU_EEPROM_SIZE		256
> +#define QNAP_MCU_EEPROM_BLOCK_SIZE	32
> +
> +static int qnap_mcu_eeprom_read_block(struct qnap_mcu *mcu, unsigned int offset,
> +				      void *val, size_t bytes)
> +{
> +	const u8 cmd[] = { 0xf7, 0xa1, offset, bytes };
> +	u8 *reply;
> +	int ret = 0;
> +
> +	reply = kzalloc(bytes + sizeof(cmd), GFP_KERNEL);
> +	if (!reply)
> +		return -ENOMEM;
> +
> +	ret = qnap_mcu_exec(mcu, cmd, sizeof(cmd), reply, bytes + sizeof(cmd));
> +	if (ret)
> +		goto out;
> +
> +	/* First bytes must mirror the sent command */
> +	if (memcmp(cmd, reply, sizeof(cmd))) {
> +		ret = -EIO;
> +		goto out;
> +	}
> +
> +	memcpy(val, reply + sizeof(cmd), bytes);
> +
> +out:
> +	kfree(reply);
> +	return ret;
> +}
> +
> +static int qnap_mcu_eeprom_read(void *priv, unsigned int offset, void *val, size_t bytes)
> +{
> +	struct qnap_mcu *mcu = priv;
> +	int pos = 0, ret;
> +	u8 *buf = val;
> +
> +	if (unlikely(!bytes))
> +		return 0;
> +
> +	while (bytes > 0) {
> +		size_t to_read = (bytes > QNAP_MCU_EEPROM_BLOCK_SIZE) ?
> +						QNAP_MCU_EEPROM_BLOCK_SIZE : bytes;
> +
> +		ret = qnap_mcu_eeprom_read_block(mcu, offset + pos, &buf[pos], to_read);
> +		if (ret < 0)
> +			return ret;
> +
> +		pos += to_read;
> +		bytes -= to_read;
> +	}
> +
> +	return 0;
> +}
> +
> +static int qnap_mcu_eeprom_probe(struct platform_device *pdev)
> +{
> +	struct qnap_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
> +	struct nvmem_config nvcfg = {};
> +	struct nvmem_device *ndev;
> +
> +	nvcfg.dev = &pdev->dev;
> +	nvcfg.of_node = pdev->dev.parent->of_node;
> +	nvcfg.name = dev_name(&pdev->dev);
> +	nvcfg.id = NVMEM_DEVID_NONE;
> +	nvcfg.owner = THIS_MODULE;
> +	nvcfg.type = NVMEM_TYPE_EEPROM;
> +	nvcfg.read_only = true;
> +	nvcfg.root_only = false;
> +	nvcfg.reg_read = qnap_mcu_eeprom_read;
> +	nvcfg.size = QNAP_MCU_EEPROM_SIZE,
> +	nvcfg.word_size = 1,
> +	nvcfg.stride = 1,
> +	nvcfg.priv = mcu,
> +
> +	ndev = devm_nvmem_register(&pdev->dev, &nvcfg);
> +	if (IS_ERR(ndev))
> +		return PTR_ERR(ndev);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver qnap_mcu_eeprom_driver = {
> +	.probe = qnap_mcu_eeprom_probe,
> +	.driver = {
> +		.name = "qnap-mcu-eeprom",
> +	},
> +};
> +module_platform_driver(qnap_mcu_eeprom_driver);
> +
> +MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
> +MODULE_DESCRIPTION("QNAP MCU EEPROM driver");
> +MODULE_LICENSE("GPL");

Re: [PATCH 2/2] nvmem: add driver for the eeprom in qnap-mcu controllers

[Lee Jones]

On Tue, 09 Sep 2025, Srinivas Kandagatla wrote:

> 
> 
> On 7/30/25 6:22 PM, Heiko Stuebner wrote:
> > The qnap-mcu also has an eeprom connected to it, that contains some
> > specific product-information like the mac addresses for the network
> > interfaces.
> > 
> > Add a nvmem driver for it.
> > 
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> >  drivers/mfd/qnap-mcu.c          |   1 +
> >  drivers/nvmem/Kconfig           |   9 +++
> >  drivers/nvmem/Makefile          |   2 +
> >  drivers/nvmem/qnap-mcu-eeprom.c | 110 ++++++++++++++++++++++++++++++++
> >  4 files changed, 122 insertions(+)
> >  create mode 100644 drivers/nvmem/qnap-mcu-eeprom.c
> > 
> In case Lee you want to take this via MFD,
> 
> Acked-by: Srinivas Kandagatla <srini@kernel.org>

Actually this patch should be split up.

I'll take the MFD part, you can take the NVMEM part.

-- 
Lee Jones [李琼斯]

Re: [PATCH 2/2] nvmem: add driver for the eeprom in qnap-mcu controllers

[Heiko Stübner]

Hi Lee,

Am Donnerstag, 11. September 2025, 10:41:19 Mitteleuropäische Sommerzeit schrieb Lee Jones:
> On Tue, 09 Sep 2025, Srinivas Kandagatla wrote:
> > On 7/30/25 6:22 PM, Heiko Stuebner wrote:
> > > The qnap-mcu also has an eeprom connected to it, that contains some
> > > specific product-information like the mac addresses for the network
> > > interfaces.
> > > 
> > > Add a nvmem driver for it.
> > > 
> > > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > > ---
> > >  drivers/mfd/qnap-mcu.c          |   1 +
> > >  drivers/nvmem/Kconfig           |   9 +++
> > >  drivers/nvmem/Makefile          |   2 +
> > >  drivers/nvmem/qnap-mcu-eeprom.c | 110 ++++++++++++++++++++++++++++++++
> > >  4 files changed, 122 insertions(+)
> > >  create mode 100644 drivers/nvmem/qnap-mcu-eeprom.c
> > > 
> > In case Lee you want to take this via MFD,
> > 
> > Acked-by: Srinivas Kandagatla <srini@kernel.org>
> 
> Actually this patch should be split up.
> 
> I'll take the MFD part, you can take the NVMEM part.

(1) the original problem was, that this patch essentially requires
  "mfd: qnap-mcu: Include linux/types.h in qnap-mcu.h shared header" [0]
to not break builds, hence was "supposed" go into the mfd tree after [0]
got applied.

But as we're close to -rc6 anyway, we can also just move things after the
next merge-window if that is better.

(2) For the splitting part, just to make sure I understand correctly, you'd
like the part of

@@ -346,6 +346,7 @@ static const struct qnap_mcu_variant qnap_ts433_mcu = {
 };
 
 static struct mfd_cell qnap_mcu_cells[] = {
+       { .name = "qnap-mcu-eeprom", },
        { .name = "qnap-mcu-input", },
        { .name = "qnap-mcu-leds", },
        { .name = "qnap-mcu-hwmon", }

to be its own patch for the mfd subsystem?

Thanks
Heiko



[0] https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next&id=e379ee309fcfa70fca4d3b03815159397e1b0551

Re: [PATCH 2/2] nvmem: add driver for the eeprom in qnap-mcu controllers

[Lee Jones]

On Thu, 11 Sep 2025, Heiko Stübner wrote:

> Hi Lee,
> 
> Am Donnerstag, 11. September 2025, 10:41:19 Mitteleuropäische Sommerzeit schrieb Lee Jones:
> > On Tue, 09 Sep 2025, Srinivas Kandagatla wrote:
> > > On 7/30/25 6:22 PM, Heiko Stuebner wrote:
> > > > The qnap-mcu also has an eeprom connected to it, that contains some
> > > > specific product-information like the mac addresses for the network
> > > > interfaces.
> > > > 
> > > > Add a nvmem driver for it.
> > > > 
> > > > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > > > ---
> > > >  drivers/mfd/qnap-mcu.c          |   1 +
> > > >  drivers/nvmem/Kconfig           |   9 +++
> > > >  drivers/nvmem/Makefile          |   2 +
> > > >  drivers/nvmem/qnap-mcu-eeprom.c | 110 ++++++++++++++++++++++++++++++++
> > > >  4 files changed, 122 insertions(+)
> > > >  create mode 100644 drivers/nvmem/qnap-mcu-eeprom.c
> > > > 
> > > In case Lee you want to take this via MFD,
> > > 
> > > Acked-by: Srinivas Kandagatla <srini@kernel.org>
> > 
> > Actually this patch should be split up.
> > 
> > I'll take the MFD part, you can take the NVMEM part.
> 
> (1) the original problem was, that this patch essentially requires
>   "mfd: qnap-mcu: Include linux/types.h in qnap-mcu.h shared header" [0]
> to not break builds, hence was "supposed" go into the mfd tree after [0]
> got applied.
> 
> But as we're close to -rc6 anyway, we can also just move things after the
> next merge-window if that is better.
> 
> (2) For the splitting part, just to make sure I understand correctly, you'd
> like the part of
> 
> @@ -346,6 +346,7 @@ static const struct qnap_mcu_variant qnap_ts433_mcu = {
>  };
>  
>  static struct mfd_cell qnap_mcu_cells[] = {
> +       { .name = "qnap-mcu-eeprom", },
>         { .name = "qnap-mcu-input", },
>         { .name = "qnap-mcu-leds", },
>         { .name = "qnap-mcu-hwmon", }
> 
> to be its own patch for the mfd subsystem?

Correct.

-- 
Lee Jones [李琼斯]

Re: (subset) [PATCH 0/2] qnap-mcu: add nvmem subdevice to read the eeprom

[Srinivas Kandagatla]

On Wed, 30 Jul 2025 19:22:46 +0200, Heiko Stuebner wrote:
> The qnap-mcu is firmware running on a Weltrend WT61P803 MCU and there is
> an eeprom connected to it, that can be read via the serial interface.
> 
> The eeprom is somewhat important, as it contains for example the
> assigned mac address for the rk3568's gmac interface on TSx33 devices.
> 
> So add a nvmem driver for it and hook it into the mfd.
> 
> [...]

Applied, thanks!

[2/2] nvmem: add driver for the eeprom in qnap-mcu controllers
      commit: 117c3f3014a929464c01622cb95b566bd27244f8

Best regards,
-- 
Srinivas Kandagatla <srini@kernel.org>