[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170127053104.GB14974@osadl.at>
Date: Fri, 27 Jan 2017 05:31:04 +0000
From: Nicholas Mc Guire <der.herr@...r.at>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Nicholas Mc Guire <hofrat@...dl.org>,
"David S. Miller" <davem@...emloft.net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: camellia: add missing declarations
On Mon, Jan 23, 2017 at 10:02:37PM +0800, Herbert Xu wrote:
> On Mon, Jan 16, 2017 at 05:06:51PM +0100, Nicholas Mc Guire wrote:
> > Add declarations for the camellia substitution box to allow a clean build.
> >
> > Signed-off-by: Nicholas Mc Guire <hofrat@...dl.org>
> > ---
> > Problem reported by sparse
> > arch/x86/crypto/camellia_glue.c:65:21: warning: symbol 'camellia_sp10011110' was not declared. Should it be static?
> > arch/x86/crypto/camellia_glue.c:154:21: warning: symbol 'camellia_sp22000222' was not declared. Should it be static?
> > arch/x86/crypto/camellia_glue.c:243:21: warning: symbol 'camellia_sp03303033' was not declared. Should it be static?
> > arch/x86/crypto/camellia_glue.c:332:21: warning: symbol 'camellia_sp00444404' was not declared. Should it be static?
> > arch/x86/crypto/camellia_glue.c:421:21: warning: symbol 'camellia_sp02220222' was not declared. Should it be static?
> > arch/x86/crypto/camellia_glue.c:510:21: warning: symbol 'camellia_sp30333033' was not declared. Should it be static?
> > arch/x86/crypto/camellia_glue.c:599:21: warning: symbol 'camellia_sp44044404' was not declared. Should it be static?
> > arch/x86/crypto/camellia_glue.c:688:21: warning: symbol 'camellia_sp11101110' was not declared. Should it be static?
> >
> > Patch was compile tested with: x86_64_defconfig +
> > CONFIG_CRYPTO_CAMELLIA_X86_64=m
> >
> > Patch is against 4.10-rc3 (localversion-next is next-20170116)
>
> This is arguably a sparse bug. These variables are only referenced
> by assembly code and already carries the __visible tag. So sparse
> should learn to suppress this warning when __visible is present.
I had assumed that __visible only would apply to LTO not to non-LTO
builds so the externally_visible attributed would not resolve this
and thus this warning seems correct.
Is this interpretation incorect ?
thx!
hofrat
Powered by blists - more mailing lists