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: <20250820071419.GI7508@google.com>
Date: Wed, 20 Aug 2025 08:14:19 +0100
From: Lee Jones <lee@...nel.org>
To: Heiko Stübner <heiko@...ech.de>
Cc: Srinivas Kandagatla <srini@...nel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the nvmem tree

On Tue, 19 Aug 2025, Heiko Stübner wrote:

> Am Dienstag, 19. August 2025, 15:58:32 Mitteleuropäische Sommerzeit schrieb Srinivas Kandagatla:
> > 
> > On 8/19/25 2:54 PM, Heiko Stübner wrote:
> > > Am Dienstag, 19. August 2025, 13:22:04 Mitteleuropäische Sommerzeit schrieb Srinivas Kandagatla:
> > >> On 8/19/25 12:14 PM, Heiko Stübner wrote:
> > >>> Hi,
> > >>>
> > >>> Am Dienstag, 19. August 2025, 05:40:39 Mitteleuropäische Sommerzeit schrieb Stephen Rothwell:
> > >>>> After merging the nvmem tree, today's linux-next build (x86_64
> > >>>> allmodconfig) failed like this:
> > >>>>
> > >>>> In file included from drivers/nvmem/qnap-mcu-eeprom.c:12:
> > >>>> include/linux/mfd/qnap-mcu.h:13:9: error: unknown type name 'u32'
> > >>>>    13 |         u32 baud_rate;
> > >>>>       |         ^~~
> > >>>
> > >>> [...]
> > >>>
> > >>>>
> > >>>> Caused by commit
> > >>>>
> > >>>>   117c3f3014a9 ("nvmem: add driver for the eeprom in qnap-mcu controllers")
> > >>>>
> > >>>> I have used the nvmem tree from next-20250818 for today.
> > >>>
> > >>> bah, sorry about messing this up.
> > >>>
> > >>> While I encountered this, and fixed that with the pending
> > >>>   https://lore.kernel.org/all/20250804130726.3180806-2-heiko@sntech.de/
> > >>>
> > >>> I completely missed that the nvmem driver applied alone would break
> > >>> without that change :-( .
> > >>
> > >> I have now reverted this change, @Heiko Please let me know if you want
> > >> to take this to mfd tree or vice-versa.
> > > 
> > > ok, no worries :-) .
> > > 
> > > I guess for now, I'll just make sure the header patch gets somewhere.
> > > And I guess I'll re-try the nvmem driver once that has happened,
> > > probably for the next cycle.
> > 
> > I don't think we need to wait till next cycle, Lee can pick up this
> > patch via mfd tree if header change is going via mfd tree.
> 
> Okay ... if that is fine with you then great.
> 
> I guess for less confusion, I'll re-submit the driver, reference the header
> patch it needs and you can Ack it to go via the mfd tree.

Sounds fine.

-- 
Lee Jones [李琼斯]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ