lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2273730.1BCLMh4Saa@diego>
Date: Thu, 11 Sep 2025 10:48:27 +0200
From: Heiko StĂĽbner <heiko@...ech.de>
To: Srinivas Kandagatla <srini@...nel.org>, Lee Jones <lee@...nel.org>
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject:
 Re: [PATCH 2/2] nvmem: add driver for the eeprom in qnap-mcu controllers

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@...ech.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@...nel.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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ