From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Andrew Morton <akpm@linux-foundation.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Mahipal Challa <Mahipal.Challa@cavium.com>
Subject: Re: linux-next: build warnings after merge of the akpm-current tree
Date: Mon, 20 Mar 2017 13:30:53 +0100 [thread overview]
Message-ID: <20170320123053.GB11825@hardcore> (raw)
In-Reply-To: <CACT4Y+b-dQYkeDg127hqRfVhTyxrDEP5vR07cH6=ei+9jtTNyg@mail.gmail.com>
On Mon, Mar 20, 2017 at 10:05:54AM +0100, Dmitry Vyukov wrote:
> On Mon, Mar 20, 2017 at 6:22 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Andrew,
> >
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) produced these warnings:
> >
> > drivers/crypto/cavium/zip/zip_main.c: In function 'zip_show_stats':
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'long long int' [-Wformat=]
> > seq_printf(s, " ZIP Device %d Stats\n"
> > ^
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 6 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 7 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 10 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 11 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 12 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 13 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 14 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 15 has type 'long long int' [-Wformat=]
> >
> > Introduced by commit
> >
> > 09ae5d37e093 ("crypto: zip - Add Compression/Decompression statistics")
> >
> > from the crypto tree interacting with commit
> >
> > 3f4ca3d25e1a ("asm-generic, x86: wrap atomic operations")
> >
> > from the akpm-current tree.
> >
> > This latter commit changed atomic64read() from "long" to "long long"
> > on x86_64.
>
> Hi,
>
> Previously atomic operations returned different types on 32/64 bits. I
> think that was pretty unfortunate and could actually lead to lots of
> such warnings (as there were no single format specifier that one could
> use portably), and was difficult to wrap. So I used "unsigned long
> long" for all operations.
> I actually suspect that the new zip_main.c code would cause a similar
> warning on 32 bits even without my change, because atomic ops already
> returned unsigned long long there.
The driver depends on 64BIT (HW is 64 bit only).
> So I think we need to fix zip_main.c.
I'm not entirely sure, all drivers that are available for x86_64 and
arm64 and use atomic64_read will show such warnings.
One possible solution would be to disable COMPILE_TEST for the zip
driver, but that would just hide the issue.
--Jan
next prev parent reply other threads:[~2017-03-20 12:30 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-20 5:22 linux-next: build warnings after merge of the akpm-current tree Stephen Rothwell
2017-03-20 9:05 ` Dmitry Vyukov
2017-03-20 12:30 ` Jan Glauber [this message]
2017-03-20 17:06 ` Challa, Mahipal
-- strict thread matches above, loose matches on Subject: below --
2022-02-09 6:02 Stephen Rothwell
2022-02-09 16:03 ` Hugh Dickins
2022-03-28 23:04 ` Matthew Wilcox
2022-03-29 3:32 ` Hugh Dickins
2022-03-24 7:27 ` Stephen Rothwell
2022-03-28 19:54 ` Hugh Dickins
2022-03-28 22:10 ` Matthew Wilcox
2021-10-11 7:31 Stephen Rothwell
2021-10-11 17:46 ` Kees Cook
2021-06-15 10:50 Stephen Rothwell
2020-10-06 12:05 Stephen Rothwell
2020-10-06 20:01 ` Peter Xu
2020-10-06 22:03 ` Stephen Rothwell
2020-01-06 6:14 Stephen Rothwell
2017-08-24 7:41 Stephen Rothwell
2017-08-24 8:15 ` Changwei Ge
2017-08-25 21:23 ` Andrew Morton
2017-08-26 1:23 ` Changwei Ge
2015-01-27 8:12 Stephen Rothwell
2015-01-27 8:27 ` Vladimir Davydov
2014-10-03 7:30 Stephen Rothwell
2014-10-03 18:21 ` Andrew Morton
2014-10-03 19:28 ` Michal Nazarewicz
2014-09-23 8:18 Stephen Rothwell
2014-08-26 7:22 Stephen Rothwell
2014-08-26 10:19 ` Xishi Qiu
2013-08-29 9:47 Stephen Rothwell
2013-08-29 11:24 ` Maxim Patlasov
2013-08-29 19:42 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170320123053.GB11825@hardcore \
--to=jan.glauber@caviumnetworks.com \
--cc=Mahipal.Challa@cavium.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).