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

[Lee Jones <lee@kernel.org>]

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 [李琼斯]