linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).