linux-kernel - Re: linux-next: build failure after merge of the nvmem tree

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <10708013.qUNvkh4Gvn@diego>
Date: Tue, 19 Aug 2025 15:54:27 +0200
From: Heiko Stübner <heiko@...ech.de>
To: Srinivas Kandagatla <srini@...nel.org>,
 Stephen Rothwell <sfr@...b.auug.org.au>,
 Srinivas Kandagatla <srini@...nel.org>
Cc: 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

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.

Creating dependencies between trees somehow does sound like
more hassle so I'll just wait for a stable base, to not cause more
breakage :-)


Heiko