[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5bc9d25c-d546-fe94-05cc-41bd5bbbaf67@gmx.de>
Date: Thu, 10 Aug 2023 17:59:30 +0200
From: Helge Deller <deller@....de>
To: Arnd Bergmann <arnd@...db.de>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Arnd Bergmann <arnd@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc: Matt Turner <mattst88@...il.com>, Vineet Gupta <vgupta@...nel.org>,
Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, guoren <guoren@...nel.org>,
Brian Cain <bcain@...cinc.com>,
Huacai Chen <chenhuacai@...nel.org>,
WANG Xuerui <kernel@...0n.name>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Michal Simek <monstr@...str.eu>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Dinh Nguyen <dinguyen@...nel.org>,
Jonas Bonn <jonas@...thpole.se>,
Stafford Horne <shorne@...il.com>,
"James E . J . Bottomley" <James.Bottomley@...senPartnership.com>,
Michael Ellerman <mpe@...erman.id.au>,
Palmer Dabbelt <palmer@...belt.com>,
Heiko Carstens <hca@...ux.ibm.com>,
John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
"x86@...nel.org" <x86@...nel.org>, Borislav Petkov <bp@...en8.de>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Guenter Roeck <linux@...ck-us.net>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-next <linux-next@...r.kernel.org>,
"linux-alpha@...r.kernel.org" <linux-alpha@...r.kernel.org>,
"linux-snps-arc@...ts.infradead.org"
<linux-snps-arc@...ts.infradead.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
"linux-hexagon@...r.kernel.org" <linux-hexagon@...r.kernel.org>,
"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
"linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"linux-openrisc@...r.kernel.org" <linux-openrisc@...r.kernel.org>,
"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
Richard Henderson <richard.henderson@...aro.org>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Rich Felker <dalias@...c.org>,
"David S . Miller" <davem@...emloft.net>,
Chris Zankel <chris@...kel.net>,
Max Filippov <jcmvbkbc@...il.com>,
Christian Brauner <brauner@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Albert Ou <aou@...s.berkeley.edu>,
Youling Tang <tangyouling@...ngson.cn>,
Tiezhu Yang <yangtiezhu@...ngson.cn>,
Masahiro Yamada <masahiroy@...nel.org>,
Randy Dunlap <rdunlap@...radead.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Miguel Ojeda <ojeda@...nel.org>,
Zhen Lei <thunder.leizhen@...wei.com>,
Xin Li <xin3.li@...el.com>, Nhat Pham <nphamcs@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Marc Aurèle La France <tsi@...oix.net>,
Johannes Weiner <hannes@...xchg.org>,
"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH 16/17] [RFC] arch: turn -Wmissing-prototypes off
conditionally
On 8/10/23 17:21, Arnd Bergmann wrote:
> On Thu, Aug 10, 2023, at 16:59, Christophe Leroy wrote:
>> Le 10/08/2023 à 16:19, Arnd Bergmann a écrit :
>>> From: Arnd Bergmann <arnd@...db.de>
>>>
>>> I have cleaned up the -Wmissing-prototypes warnings for most of the major architectures
>>> as well as all drivers that get enabled for CONFIG_COMPILE_TEST, so now these should be
>>> close to fixed on x86, arm, arm64, powerpc, s390, and riscv.
>>>
>>> The other architectures tend to have a lot of these warning in architecture specific
>>> code, primarily from functions that are only called from assembler code and do
>>> not otherwise need a declaration but still cause a warning without one. Other cases
>>> are simply functions that should just be static or are missing an #include statement.
>>>
>>> In order to be able to turn the warning on globally by default without breaking all
>>> these architectures, add a list of exceptions for architecture directories that
>>> can revert back to the old behavior of not warning based on a new
>>> CONFIG_WNO_MISSING_PROTOTYPES option.
>>
>> Some architectures only have a few of those errors/warnings.
>>
>> For instance microblaze and parisc only have one each. Isn't it better
>> to fix them rather then turn the errors off ?
>
> The list was only the 'defconfig' warnings, there are a couple more
> that I saw with 'allmodconfig', and I'm sure there are even more
> when dealing with other random configurations.
>
> I did send other fixes for microblaze and parisc specific drivers,
> and I could also send patches for the two defconfig warnings if
> the maintainers are happy with fixing those but leaving allmodconfig
> to still warn, but I feel that it's easier for them to just
> do the last fixes themselves and then remove my hack again.
>
> I'll wait for Michal and Helge on these.
Arnd, I like your patch!
For parisc I've done quite some work during the last few weeks to
get such warnings sqeezed out, so please drop the hunk for parisc from
your patch. My plan is to become warning-free before 6.5-final.
This last one:
arch/parisc/lib/ucmpdi2.c:12:5: error: no previous prototype for '__ucmpdi2' [-Werror=missing-prototypes]
I'll take care in the parisc for-next tree.
Thanks!
Helge
>> Others like loongarch which is a recent actively maintained
>> architecture, I'd expect the 30 errors to be easy to fix.
>
> Agreed, they probably are.
>
>> Many of the alpha ones seems to be brought by your commit e19d4ebc536d
>> ("alpha: add full ioread64/iowrite64 implementation")
>
> As far as I can see, those already existing before that patch, though
> I did touch the same lines there.
>
> In the end it's a matter of where to stop, as there are endless
> configurations to test if I want to do a complete job. I drew the
> line between powerpc (which I tried to fix) and mips (which I left
> alone), mainly because the powerpc side was already exhausting
> and mips has even more obscure configurations. The other ones on
> the list are all less actively maintained than these two.
>
> Arnd
Powered by blists - more mailing lists