On Thu, Jul 14, 2022 at 12:23 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > Oh, it's not just this one. The lists of build regressions between v5.18 > and v5.19-rc1 [1] resp. v5.19-rc6 [2] look surprisingly similar :-( > > [1] https://lore.kernel.org/all/20220606082201.2792145-1-geert@xxxxxxxxxxxxxx > [2] https://lore.kernel.org/all/20220711064425.3084093-1-geert@xxxxxxxxxxxxxx Hmm. Some of them are because UM ends up defining and exposing helper functions like "to_phys()", which it just shouldn't do. Very generic name - so when some driver ends up using the same name, you get those errors. And some look positively strange. Like that drivers/mfd/asic3.c: error: unused variable 'asic' [-Werror=unused-variable]: => 941:23 which is clearly used three lines later by iounmap(asic->tmio_cnf); and I can't find any case of 'iounmap()' having been defined to an empty macro or anything like that to explain it. The error in drivers/tty/serial/sh-sci.c looks to be exactly the same issue, just with ioremap() instead of iounmap(). It would be good to have some way to find which build/architecture it is, because right now it just looks bogus. Do you perhaps use some broken compiler that complains when the empty inline functions don't use their arguments? Because that's what those ioremap/iounmap() ones look like to me, but there might be some magical architecture / config that has issues that aren't obvious. IOW, I'd love to get those fixed, but I would also want a little bit more info. Linus
