From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752883AbbKLUxN (ORCPT ); Thu, 12 Nov 2015 15:53:13 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:51838 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752024AbbKLUxM (ORCPT ); Thu, 12 Nov 2015 15:53:12 -0500 From: Arnd Bergmann To: David Miller 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 Message-ID: <3729464.5X0HBxzvx5@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151112.122528.1794206832971213176.davem@davemloft.net> References: <4391788.dtYArQ4mVi@wuerfel> <20151112.122528.1794206832971213176.davem@davemloft.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:qvbd2093gdQXHt4zkSkV89QglBiKqkBjaylll3edeyE6ud76g3e cv5yeuUQEtvI3qqnuKpuYGQf2j5nuIeQ2auKNM7On3inLqkAGzMBalbongTkzogk7lsVgSN TSQ/c+M6U6lWC6a2S6yJZUvSP3bX6fCkxBeeM0R32zaOpfTj3X2LuXgrmNhhS8e/af2CB9F QqmjI/5o7ND5E4pzUQHFw== X-UI-Out-Filterresults: notjunk:1;V01:K0:AWiREly/y3k=:nqCv8vPJf04MQOFiQsti10 MJbF+Ykv5MLb6UV4K2L4WfAlgG9UKTA1jzUNXSZUqwDxDVh3rz5/QpjQfZNaFCqggl/s3seim 1MjocG07N4wCzOj9NUCnjoskc70R74Sh+6dWmVsYBzidWbckiUOg3HaoG15Kv/QCK9mJRTBPy opzdUViviWXgqpKFbGhSQD/v7RvW/h2AYeQ1qxWnwdJTGT7jYxJ7fbQK26ba/G9aItGlWn/kK 2UsJDFuv7PU20UjBTqvuXAQr3ZCCiy+h1Mq/VK0UYosQdyYrzXEpnFj2URnluaUAa4CGf9LMv RW50Nm5Z2ooANCB8mgEPPlPH4zataXXPI5vIqgM/DIPmbeliuE645nz1hDDc5MDB5vLeO5mhR VrOJBiVJqfaKmpYLVUC8yU/3IRQn3YS4dzlHQwYoNxgnoy16ZEDaIAed+UXCa6gwZjckvXRp7 yHm8wkaL9cGSNFlol3DDRokzBG/KrZM9GuZs4f6gJPibyRqrL+SUuQfxnhc5IxqYPnmFyjII+ 0b9+52kx/gR2tc2PMqsaOQRdJlJxjQX033GoZMaC4yW5fcgMxd3bJkHDfqII4kESwacXiAhrP W8BRpV1Pz6sOw0ekiZ6HrRq4wvRl++vVkvEmLmqPU4EwZcyybixJOFfeD7exvdReTiju7Srpa 1Qw4sMB2mNMhdSmkc/nukD45/fpqmsHH0ABSvTBrb1bPyev1AMSvtLMgySU+8TkCeflqJz/ko 3BpIDLKkrx09rb8a Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 12 November 2015 12:25:28 David Miller wrote: > From: Arnd Bergmann > 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 > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Thu, 12 Nov 2015 21:52:30 +0100 Subject: [PATCH] stmmac: avoid ipq806x constant overflow warning In-Reply-To: <20151112.122528.1794206832971213176.davem@davemloft.net> References: <4391788.dtYArQ4mVi@wuerfel> <20151112.122528.1794206832971213176.davem@davemloft.net> Message-ID: <3729464.5X0HBxzvx5@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thursday 12 November 2015 12:25:28 David Miller wrote: > From: Arnd Bergmann > 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 > > 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