From: Arnd Bergmann <arnd@arndb.de> To: David Miller <davem@davemloft.net> Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, mathieu@codeaurora.org, peppe.cavallaro@st.com Subject: Re: [PATCH] stmmac: avoid ipq806x constant overflow warning Date: Thu, 12 Nov 2015 21:52:30 +0100 [thread overview] Message-ID: <3729464.5X0HBxzvx5@wuerfel> (raw) In-Reply-To: <20151112.122528.1794206832971213176.davem@davemloft.net> On Thursday 12 November 2015 12:25:28 David Miller wrote: > From: Arnd Bergmann <arnd@arndb.de> > Date: Thu, 12 Nov 2015 15:12:48 +0100 > > > Building dwmac-ipq806x on a 64-bit architecture produces a harmless > > warning from gcc: > > > > stmmac/dwmac-ipq806x.c: In function 'ipq806x_gmac_probe': > > include/linux/bitops.h:6:19: warning: overflow in implicit constant conversion [-Woverflow] > > val = QSGMII_PHY_CDR_EN | > > stmmac/dwmac-ipq806x.c:333:8: note: in expansion of macro 'QSGMII_PHY_CDR_EN' > > #define QSGMII_PHY_CDR_EN BIT(0) > > #define BIT(nr) (1UL << (nr)) > > > > The compiler warns about the fact that a 64-bit literal is passed > > into a function that takes a 32-bit argument. I could not fully understand > > why it warns despite the fact that this number is always small enough > > to fit, but changing the use of BIT() macros into the equivalent hexadecimal > > representation avoids the warning > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > Fixes: b1c17215d718 ("stmmac: add ipq806x glue layer") > > I've seen this warning too on x86_64 and had been meaning to look > into it, thanks for taking the initiative. > > Moving away from using BIT() is somewhat disappointing, because we > want to encourage people to use these macros. Ok, I never really liked that macro, so I didn't mind removing it. ;-) I spent too much time working at IBM where all internal documentation uses bit numbers that call the MSB bit 0, and drivers use randomly either the IBM notation or the one that everyone else uses, so I always found the hex numbers way more intuitive. > Also I don't even understand the compiler's behavior, it's warning > about QSGMII_PHY_CDR_EN but if you define only that to "0x1u" it still > warns about QSGMII_PHY_CDR_EN. > > The warning goes away only if you change all 5 BIT() uses. Yes, I have spent the time to analyze the problem now and it all makes sense. A proper patch follows. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] stmmac: avoid ipq806x constant overflow warning Date: Thu, 12 Nov 2015 21:52:30 +0100 [thread overview] Message-ID: <3729464.5X0HBxzvx5@wuerfel> (raw) In-Reply-To: <20151112.122528.1794206832971213176.davem@davemloft.net> On Thursday 12 November 2015 12:25:28 David Miller wrote: > From: Arnd Bergmann <arnd@arndb.de> > Date: Thu, 12 Nov 2015 15:12:48 +0100 > > > Building dwmac-ipq806x on a 64-bit architecture produces a harmless > > warning from gcc: > > > > stmmac/dwmac-ipq806x.c: In function 'ipq806x_gmac_probe': > > include/linux/bitops.h:6:19: warning: overflow in implicit constant conversion [-Woverflow] > > val = QSGMII_PHY_CDR_EN | > > stmmac/dwmac-ipq806x.c:333:8: note: in expansion of macro 'QSGMII_PHY_CDR_EN' > > #define QSGMII_PHY_CDR_EN BIT(0) > > #define BIT(nr) (1UL << (nr)) > > > > The compiler warns about the fact that a 64-bit literal is passed > > into a function that takes a 32-bit argument. I could not fully understand > > why it warns despite the fact that this number is always small enough > > to fit, but changing the use of BIT() macros into the equivalent hexadecimal > > representation avoids the warning > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > Fixes: b1c17215d718 ("stmmac: add ipq806x glue layer") > > I've seen this warning too on x86_64 and had been meaning to look > into it, thanks for taking the initiative. > > Moving away from using BIT() is somewhat disappointing, because we > want to encourage people to use these macros. Ok, I never really liked that macro, so I didn't mind removing it. ;-) I spent too much time working at IBM where all internal documentation uses bit numbers that call the MSB bit 0, and drivers use randomly either the IBM notation or the one that everyone else uses, so I always found the hex numbers way more intuitive. > Also I don't even understand the compiler's behavior, it's warning > about QSGMII_PHY_CDR_EN but if you define only that to "0x1u" it still > warns about QSGMII_PHY_CDR_EN. > > The warning goes away only if you change all 5 BIT() uses. Yes, I have spent the time to analyze the problem now and it all makes sense. A proper patch follows. Arnd
next prev parent reply other threads:[~2015-11-12 20:53 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-11-12 14:12 [PATCH] stmmac: avoid ipq806x constant overflow warning Arnd Bergmann 2015-11-12 14:12 ` Arnd Bergmann 2015-11-12 17:25 ` David Miller 2015-11-12 17:25 ` David Miller 2015-11-12 20:52 ` Arnd Bergmann [this message] 2015-11-12 20:52 ` Arnd Bergmann 2015-11-12 21:03 ` [PATCH v2] " Arnd Bergmann 2015-11-12 21:03 ` Arnd Bergmann 2015-11-12 21:12 ` David Miller 2015-11-12 21:12 ` David Miller 2015-11-13 7:37 ` Geert Uytterhoeven 2015-11-13 7:37 ` Geert Uytterhoeven 2015-11-13 7:37 ` Geert Uytterhoeven 2015-11-13 7:52 ` Joe Perches 2015-11-13 7:52 ` Joe Perches 2015-11-13 7:52 ` Joe Perches 2015-11-13 8:00 ` Geert Uytterhoeven 2015-11-13 8:00 ` Geert Uytterhoeven 2015-11-13 8:00 ` Geert Uytterhoeven
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=3729464.5X0HBxzvx5@wuerfel \ --to=arnd@arndb.de \ --cc=davem@davemloft.net \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mathieu@codeaurora.org \ --cc=netdev@vger.kernel.org \ --cc=peppe.cavallaro@st.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.