* [PATCH] stmmac: avoid ipq806x constant overflow warning @ 2015-11-12 14:12 ` Arnd Bergmann 0 siblings, 0 replies; 19+ messages in thread From: Arnd Bergmann @ 2015-11-12 14:12 UTC (permalink / raw) To: netdev Cc: linux-kernel, linux-arm-kernel, Mathieu Olivari, David S. Miller, Giuseppe Cavallaro 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") --- This came up on the arm64 allmodconfig build diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c index 9d89bdbf029f..4abd9b0b542a 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c @@ -77,11 +77,11 @@ /* Only GMAC1/2/3 support SGMII and their CTL register are not contiguous */ #define QSGMII_PHY_SGMII_CTL(x) ((x == 1) ? 0x134 : \ (0x13c + (4 * (x - 2)))) -#define QSGMII_PHY_CDR_EN BIT(0) -#define QSGMII_PHY_RX_FRONT_EN BIT(1) -#define QSGMII_PHY_RX_SIGNAL_DETECT_EN BIT(2) -#define QSGMII_PHY_TX_DRIVER_EN BIT(3) -#define QSGMII_PHY_QSGMII_EN BIT(7) +#define QSGMII_PHY_CDR_EN 0x01u +#define QSGMII_PHY_RX_FRONT_EN 0x02u +#define QSGMII_PHY_RX_SIGNAL_DETECT_EN 0x04u +#define QSGMII_PHY_TX_DRIVER_EN 0x08u +#define QSGMII_PHY_QSGMII_EN 0x80u #define QSGMII_PHY_PHASE_LOOP_GAIN_OFFSET 12 #define QSGMII_PHY_PHASE_LOOP_GAIN_MASK 0x7 #define QSGMII_PHY_RX_DC_BIAS_OFFSET 18 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH] stmmac: avoid ipq806x constant overflow warning @ 2015-11-12 14:12 ` Arnd Bergmann 0 siblings, 0 replies; 19+ messages in thread From: Arnd Bergmann @ 2015-11-12 14:12 UTC (permalink / raw) To: linux-arm-kernel 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") --- This came up on the arm64 allmodconfig build diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c index 9d89bdbf029f..4abd9b0b542a 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c @@ -77,11 +77,11 @@ /* Only GMAC1/2/3 support SGMII and their CTL register are not contiguous */ #define QSGMII_PHY_SGMII_CTL(x) ((x == 1) ? 0x134 : \ (0x13c + (4 * (x - 2)))) -#define QSGMII_PHY_CDR_EN BIT(0) -#define QSGMII_PHY_RX_FRONT_EN BIT(1) -#define QSGMII_PHY_RX_SIGNAL_DETECT_EN BIT(2) -#define QSGMII_PHY_TX_DRIVER_EN BIT(3) -#define QSGMII_PHY_QSGMII_EN BIT(7) +#define QSGMII_PHY_CDR_EN 0x01u +#define QSGMII_PHY_RX_FRONT_EN 0x02u +#define QSGMII_PHY_RX_SIGNAL_DETECT_EN 0x04u +#define QSGMII_PHY_TX_DRIVER_EN 0x08u +#define QSGMII_PHY_QSGMII_EN 0x80u #define QSGMII_PHY_PHASE_LOOP_GAIN_OFFSET 12 #define QSGMII_PHY_PHASE_LOOP_GAIN_MASK 0x7 #define QSGMII_PHY_RX_DC_BIAS_OFFSET 18 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH] stmmac: avoid ipq806x constant overflow warning 2015-11-12 14:12 ` Arnd Bergmann @ 2015-11-12 17:25 ` David Miller -1 siblings, 0 replies; 19+ messages in thread From: David Miller @ 2015-11-12 17:25 UTC (permalink / raw) To: arnd; +Cc: netdev, linux-kernel, linux-arm-kernel, mathieu, peppe.cavallaro 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. I think it's also easier from a driver author and auditing perspective, you can see that something is being defined as bit X and then check the documentation for the chip to see if bit X is correct or not. With the hex values there is more mental work and room for... mistakes. 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. This makes me like the change even less, something foul is going on here and I'd rather figure out what that is than install this patch. Thanks. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH] stmmac: avoid ipq806x constant overflow warning @ 2015-11-12 17:25 ` David Miller 0 siblings, 0 replies; 19+ messages in thread From: David Miller @ 2015-11-12 17:25 UTC (permalink / raw) To: linux-arm-kernel 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. I think it's also easier from a driver author and auditing perspective, you can see that something is being defined as bit X and then check the documentation for the chip to see if bit X is correct or not. With the hex values there is more mental work and room for... mistakes. 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. This makes me like the change even less, something foul is going on here and I'd rather figure out what that is than install this patch. Thanks. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] stmmac: avoid ipq806x constant overflow warning 2015-11-12 17:25 ` David Miller @ 2015-11-12 20:52 ` Arnd Bergmann -1 siblings, 0 replies; 19+ messages in thread From: Arnd Bergmann @ 2015-11-12 20:52 UTC (permalink / raw) To: David Miller Cc: netdev, linux-kernel, linux-arm-kernel, mathieu, peppe.cavallaro 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH] stmmac: avoid ipq806x constant overflow warning @ 2015-11-12 20:52 ` Arnd Bergmann 0 siblings, 0 replies; 19+ messages in thread From: Arnd Bergmann @ 2015-11-12 20:52 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2] stmmac: avoid ipq806x constant overflow warning 2015-11-12 20:52 ` Arnd Bergmann @ 2015-11-12 21:03 ` Arnd Bergmann -1 siblings, 0 replies; 19+ messages in thread From: Arnd Bergmann @ 2015-11-12 21:03 UTC (permalink / raw) To: linux-arm-kernel Cc: David Miller, netdev, mathieu, linux-kernel, peppe.cavallaro 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)) This is a result of the type conversion rules in C, when we take the logical OR of multiple different types. In particular, we have and unsigned long QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == 0x0000000000000001ul and a signed int 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 which together gives a signed long value 0xffffffffc0000001l and when this is passed into a function that takes an unsigned int type, gcc warns about the signed overflow and the loss of the upper 32-bits that are all ones. This patch adds 'ul' type modifiers to the literal numbers passed in here, so now the expression remains an 'unsigned long' with the upper bits all zero, and that avoids the signed overflow and the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: b1c17215d718 ("stmmac: add ipq806x glue layer") diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c index 9d89bdbf029f..82de68b1a452 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c @@ -337,11 +337,11 @@ static int ipq806x_gmac_probe(struct platform_device *pdev) QSGMII_PHY_RX_SIGNAL_DETECT_EN | QSGMII_PHY_TX_DRIVER_EN | QSGMII_PHY_QSGMII_EN | - 0x4 << QSGMII_PHY_PHASE_LOOP_GAIN_OFFSET | - 0x3 << QSGMII_PHY_RX_DC_BIAS_OFFSET | - 0x1 << QSGMII_PHY_RX_INPUT_EQU_OFFSET | - 0x2 << QSGMII_PHY_CDR_PI_SLEW_OFFSET | - 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET); + 0x4ul << QSGMII_PHY_PHASE_LOOP_GAIN_OFFSET | + 0x3ul << QSGMII_PHY_RX_DC_BIAS_OFFSET | + 0x1ul << QSGMII_PHY_RX_INPUT_EQU_OFFSET | + 0x2ul << QSGMII_PHY_CDR_PI_SLEW_OFFSET | + 0xCul << QSGMII_PHY_TX_DRV_AMP_OFFSET); } plat_dat->has_gmac = true; ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH v2] stmmac: avoid ipq806x constant overflow warning @ 2015-11-12 21:03 ` Arnd Bergmann 0 siblings, 0 replies; 19+ messages in thread From: Arnd Bergmann @ 2015-11-12 21:03 UTC (permalink / raw) To: linux-arm-kernel 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)) This is a result of the type conversion rules in C, when we take the logical OR of multiple different types. In particular, we have and unsigned long QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == 0x0000000000000001ul and a signed int 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 which together gives a signed long value 0xffffffffc0000001l and when this is passed into a function that takes an unsigned int type, gcc warns about the signed overflow and the loss of the upper 32-bits that are all ones. This patch adds 'ul' type modifiers to the literal numbers passed in here, so now the expression remains an 'unsigned long' with the upper bits all zero, and that avoids the signed overflow and the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: b1c17215d718 ("stmmac: add ipq806x glue layer") diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c index 9d89bdbf029f..82de68b1a452 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c @@ -337,11 +337,11 @@ static int ipq806x_gmac_probe(struct platform_device *pdev) QSGMII_PHY_RX_SIGNAL_DETECT_EN | QSGMII_PHY_TX_DRIVER_EN | QSGMII_PHY_QSGMII_EN | - 0x4 << QSGMII_PHY_PHASE_LOOP_GAIN_OFFSET | - 0x3 << QSGMII_PHY_RX_DC_BIAS_OFFSET | - 0x1 << QSGMII_PHY_RX_INPUT_EQU_OFFSET | - 0x2 << QSGMII_PHY_CDR_PI_SLEW_OFFSET | - 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET); + 0x4ul << QSGMII_PHY_PHASE_LOOP_GAIN_OFFSET | + 0x3ul << QSGMII_PHY_RX_DC_BIAS_OFFSET | + 0x1ul << QSGMII_PHY_RX_INPUT_EQU_OFFSET | + 0x2ul << QSGMII_PHY_CDR_PI_SLEW_OFFSET | + 0xCul << QSGMII_PHY_TX_DRV_AMP_OFFSET); } plat_dat->has_gmac = true; ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH v2] stmmac: avoid ipq806x constant overflow warning 2015-11-12 21:03 ` Arnd Bergmann @ 2015-11-12 21:12 ` David Miller -1 siblings, 0 replies; 19+ messages in thread From: David Miller @ 2015-11-12 21:12 UTC (permalink / raw) To: arnd; +Cc: linux-arm-kernel, netdev, mathieu, linux-kernel, peppe.cavallaro From: Arnd Bergmann <arnd@arndb.de> Date: Thu, 12 Nov 2015 22:03:40 +0100 > @@ -337,11 +337,11 @@ static int ipq806x_gmac_probe(struct platform_device *pdev) > QSGMII_PHY_RX_SIGNAL_DETECT_EN | > QSGMII_PHY_TX_DRIVER_EN | > QSGMII_PHY_QSGMII_EN | > - 0x4 << QSGMII_PHY_PHASE_LOOP_GAIN_OFFSET | > - 0x3 << QSGMII_PHY_RX_DC_BIAS_OFFSET | > - 0x1 << QSGMII_PHY_RX_INPUT_EQU_OFFSET | > - 0x2 << QSGMII_PHY_CDR_PI_SLEW_OFFSET | > - 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET); > + 0x4ul << QSGMII_PHY_PHASE_LOOP_GAIN_OFFSET | > + 0x3ul << QSGMII_PHY_RX_DC_BIAS_OFFSET | > + 0x1ul << QSGMII_PHY_RX_INPUT_EQU_OFFSET | > + 0x2ul << QSGMII_PHY_CDR_PI_SLEW_OFFSET | > + 0xCul << QSGMII_PHY_TX_DRV_AMP_OFFSET); > } > Indeed, this looks so much better. Applied. Thanks for looking more deeply into this! ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2] stmmac: avoid ipq806x constant overflow warning @ 2015-11-12 21:12 ` David Miller 0 siblings, 0 replies; 19+ messages in thread From: David Miller @ 2015-11-12 21:12 UTC (permalink / raw) To: linux-arm-kernel From: Arnd Bergmann <arnd@arndb.de> Date: Thu, 12 Nov 2015 22:03:40 +0100 > @@ -337,11 +337,11 @@ static int ipq806x_gmac_probe(struct platform_device *pdev) > QSGMII_PHY_RX_SIGNAL_DETECT_EN | > QSGMII_PHY_TX_DRIVER_EN | > QSGMII_PHY_QSGMII_EN | > - 0x4 << QSGMII_PHY_PHASE_LOOP_GAIN_OFFSET | > - 0x3 << QSGMII_PHY_RX_DC_BIAS_OFFSET | > - 0x1 << QSGMII_PHY_RX_INPUT_EQU_OFFSET | > - 0x2 << QSGMII_PHY_CDR_PI_SLEW_OFFSET | > - 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET); > + 0x4ul << QSGMII_PHY_PHASE_LOOP_GAIN_OFFSET | > + 0x3ul << QSGMII_PHY_RX_DC_BIAS_OFFSET | > + 0x1ul << QSGMII_PHY_RX_INPUT_EQU_OFFSET | > + 0x2ul << QSGMII_PHY_CDR_PI_SLEW_OFFSET | > + 0xCul << QSGMII_PHY_TX_DRV_AMP_OFFSET); > } > Indeed, this looks so much better. Applied. Thanks for looking more deeply into this! ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] stmmac: avoid ipq806x constant overflow warning 2015-11-12 21:03 ` Arnd Bergmann (?) @ 2015-11-13 7:37 ` Geert Uytterhoeven -1 siblings, 0 replies; 19+ messages in thread From: Geert Uytterhoeven @ 2015-11-13 7:37 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, David Miller, netdev, mathieu, linux-kernel, Giuseppe Cavallaro On Thu, Nov 12, 2015 at 10:03 PM, Arnd Bergmann <arnd@arndb.de> wrote: > 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)) > > This is a result of the type conversion rules in C, when we take the > logical OR of multiple different types. In particular, we have > and unsigned long > > QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == 0x0000000000000001ul > > and a signed int > > 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 > > which together gives a signed long value > > 0xffffffffc0000001l > > and when this is passed into a function that takes an unsigned int type, > gcc warns about the signed overflow and the loss of the upper 32-bits that > are all ones. > > This patch adds 'ul' type modifiers to the literal numbers passed in > here, so now the expression remains an 'unsigned long' with the upper > bits all zero, and that avoids the signed overflow and the warning. FWIW, the 64-bitness of BIT() on 64-bit platforms is also causing subtle warnings in other places, e.g. when inverting them to create bit mask, cfr. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a9efeca613a8fe5281d7c91f5c8c9ea46f2312f6 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2] stmmac: avoid ipq806x constant overflow warning @ 2015-11-13 7:37 ` Geert Uytterhoeven 0 siblings, 0 replies; 19+ messages in thread From: Geert Uytterhoeven @ 2015-11-13 7:37 UTC (permalink / raw) To: linux-arm-kernel On Thu, Nov 12, 2015 at 10:03 PM, Arnd Bergmann <arnd@arndb.de> wrote: > 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)) > > This is a result of the type conversion rules in C, when we take the > logical OR of multiple different types. In particular, we have > and unsigned long > > QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == 0x0000000000000001ul > > and a signed int > > 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 > > which together gives a signed long value > > 0xffffffffc0000001l > > and when this is passed into a function that takes an unsigned int type, > gcc warns about the signed overflow and the loss of the upper 32-bits that > are all ones. > > This patch adds 'ul' type modifiers to the literal numbers passed in > here, so now the expression remains an 'unsigned long' with the upper > bits all zero, and that avoids the signed overflow and the warning. FWIW, the 64-bitness of BIT() on 64-bit platforms is also causing subtle warnings in other places, e.g. when inverting them to create bit mask, cfr. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a9efeca613a8fe5281d7c91f5c8c9ea46f2312f6 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] stmmac: avoid ipq806x constant overflow warning @ 2015-11-13 7:37 ` Geert Uytterhoeven 0 siblings, 0 replies; 19+ messages in thread From: Geert Uytterhoeven @ 2015-11-13 7:37 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, David Miller, netdev, mathieu, linux-kernel, Giuseppe Cavallaro On Thu, Nov 12, 2015 at 10:03 PM, Arnd Bergmann <arnd@arndb.de> wrote: > 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)) > > This is a result of the type conversion rules in C, when we take the > logical OR of multiple different types. In particular, we have > and unsigned long > > QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == 0x0000000000000001ul > > and a signed int > > 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 > > which together gives a signed long value > > 0xffffffffc0000001l > > and when this is passed into a function that takes an unsigned int type, > gcc warns about the signed overflow and the loss of the upper 32-bits that > are all ones. > > This patch adds 'ul' type modifiers to the literal numbers passed in > here, so now the expression remains an 'unsigned long' with the upper > bits all zero, and that avoids the signed overflow and the warning. FWIW, the 64-bitness of BIT() on 64-bit platforms is also causing subtle warnings in other places, e.g. when inverting them to create bit mask, cfr. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a9efeca613a8fe5281d7c91f5c8c9ea46f2312f6 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] stmmac: avoid ipq806x constant overflow warning 2015-11-13 7:37 ` Geert Uytterhoeven (?) @ 2015-11-13 7:52 ` Joe Perches -1 siblings, 0 replies; 19+ messages in thread From: Joe Perches @ 2015-11-13 7:52 UTC (permalink / raw) To: Geert Uytterhoeven, Arnd Bergmann Cc: linux-arm-kernel, David Miller, netdev, mathieu, linux-kernel, Giuseppe Cavallaro On Fri, 2015-11-13 at 08:37 +0100, Geert Uytterhoeven wrote: > On Thu, Nov 12, 2015 at 10:03 PM, Arnd Bergmann <arnd@arndb.de> > wrote: > > 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)) > > > > This is a result of the type conversion rules in C, when we take > > the > > logical OR of multiple different types. In particular, we have > > and unsigned long > > > > QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == > > 0x0000000000000001ul > > > > and a signed int > > > > 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 > > > > which together gives a signed long value > > > > 0xffffffffc0000001l > > > > and when this is passed into a function that takes an unsigned int > > type, > > gcc warns about the signed overflow and the loss of the upper 32 > > -bits that > > are all ones. > > > > This patch adds 'ul' type modifiers to the literal numbers passed > > in > > here, so now the expression remains an 'unsigned long' with the > > upper > > bits all zero, and that avoids the signed overflow and the warning. > > FWIW, the 64-bitness of BIT() on 64-bit platforms is also causing > subtle > warnings in other places, e.g. when inverting them to create bit > mask, cfr. > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi > t/?id=a9efeca613a8fe5281d7c91f5c8c9ea46f2312f6 > > Gr{oetje,eeting}s, I still think specific length BIT macros can be useful. https://lkml.org/lkml/2015/10/16/852 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2] stmmac: avoid ipq806x constant overflow warning @ 2015-11-13 7:52 ` Joe Perches 0 siblings, 0 replies; 19+ messages in thread From: Joe Perches @ 2015-11-13 7:52 UTC (permalink / raw) To: linux-arm-kernel On Fri, 2015-11-13 at 08:37 +0100, Geert Uytterhoeven wrote: > On Thu, Nov 12, 2015 at 10:03 PM, Arnd Bergmann <arnd@arndb.de> > wrote: > > 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)) > > > > This is a result of the type conversion rules in C, when we take > > the > > logical OR of multiple different types. In particular, we have > > and unsigned long > > > > QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == > > 0x0000000000000001ul > > > > and a signed int > > > > 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 > > > > which together gives a signed long value > > > > 0xffffffffc0000001l > > > > and when this is passed into a function that takes an unsigned int > > type, > > gcc warns about the signed overflow and the loss of the upper 32 > > -bits that > > are all ones. > > > > This patch adds 'ul' type modifiers to the literal numbers passed > > in > > here, so now the expression remains an 'unsigned long' with the > > upper > > bits all zero, and that avoids the signed overflow and the warning. > > FWIW, the 64-bitness of BIT() on 64-bit platforms is also causing > subtle > warnings in other places, e.g. when inverting them to create bit > mask, cfr. > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi > t/?id=a9efeca613a8fe5281d7c91f5c8c9ea46f2312f6 > > Gr{oetje,eeting}s, I still think specific length BIT macros can be useful. https://lkml.org/lkml/2015/10/16/852 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] stmmac: avoid ipq806x constant overflow warning @ 2015-11-13 7:52 ` Joe Perches 0 siblings, 0 replies; 19+ messages in thread From: Joe Perches @ 2015-11-13 7:52 UTC (permalink / raw) To: Geert Uytterhoeven, Arnd Bergmann Cc: linux-arm-kernel, David Miller, netdev, mathieu, linux-kernel, Giuseppe Cavallaro On Fri, 2015-11-13 at 08:37 +0100, Geert Uytterhoeven wrote: > On Thu, Nov 12, 2015 at 10:03 PM, Arnd Bergmann <arnd@arndb.de> > wrote: > > 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)) > > > > This is a result of the type conversion rules in C, when we take > > the > > logical OR of multiple different types. In particular, we have > > and unsigned long > > > > QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == > > 0x0000000000000001ul > > > > and a signed int > > > > 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 > > > > which together gives a signed long value > > > > 0xffffffffc0000001l > > > > and when this is passed into a function that takes an unsigned int > > type, > > gcc warns about the signed overflow and the loss of the upper 32 > > -bits that > > are all ones. > > > > This patch adds 'ul' type modifiers to the literal numbers passed > > in > > here, so now the expression remains an 'unsigned long' with the > > upper > > bits all zero, and that avoids the signed overflow and the warning. > > FWIW, the 64-bitness of BIT() on 64-bit platforms is also causing > subtle > warnings in other places, e.g. when inverting them to create bit > mask, cfr. > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi > t/?id=a9efeca613a8fe5281d7c91f5c8c9ea46f2312f6 > > Gr{oetje,eeting}s, I still think specific length BIT macros can be useful. https://lkml.org/lkml/2015/10/16/852 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] stmmac: avoid ipq806x constant overflow warning 2015-11-13 7:52 ` Joe Perches (?) @ 2015-11-13 8:00 ` Geert Uytterhoeven -1 siblings, 0 replies; 19+ messages in thread From: Geert Uytterhoeven @ 2015-11-13 8:00 UTC (permalink / raw) To: Joe Perches Cc: Arnd Bergmann, linux-arm-kernel, David Miller, netdev, mathieu, linux-kernel, Giuseppe Cavallaro Hi Joe, On Fri, Nov 13, 2015 at 8:52 AM, Joe Perches <joe@perches.com> wrote: > On Fri, 2015-11-13 at 08:37 +0100, Geert Uytterhoeven wrote: >> On Thu, Nov 12, 2015 at 10:03 PM, Arnd Bergmann <arnd@arndb.de> >> wrote: >> > 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)) >> > >> > This is a result of the type conversion rules in C, when we take >> > the >> > logical OR of multiple different types. In particular, we have >> > and unsigned long >> > >> > QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == >> > 0x0000000000000001ul >> > >> > and a signed int >> > >> > 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 >> > >> > which together gives a signed long value >> > >> > 0xffffffffc0000001l >> > >> > and when this is passed into a function that takes an unsigned int >> > type, >> > gcc warns about the signed overflow and the loss of the upper 32 >> > -bits that >> > are all ones. >> > >> > This patch adds 'ul' type modifiers to the literal numbers passed >> > in >> > here, so now the expression remains an 'unsigned long' with the >> > upper >> > bits all zero, and that avoids the signed overflow and the warning. >> >> FWIW, the 64-bitness of BIT() on 64-bit platforms is also causing >> subtle >> warnings in other places, e.g. when inverting them to create bit >> mask, cfr. >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi >> t/?id=a9efeca613a8fe5281d7c91f5c8c9ea46f2312f6 > > I still think specific length BIT macros > can be useful. > > https://lkml.org/lkml/2015/10/16/852 Yeah! I only recently started liking the BIT() macro (before I preferred hex, too). Perhaps because Renesas datasheets use bit numbers all over the place ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2] stmmac: avoid ipq806x constant overflow warning @ 2015-11-13 8:00 ` Geert Uytterhoeven 0 siblings, 0 replies; 19+ messages in thread From: Geert Uytterhoeven @ 2015-11-13 8:00 UTC (permalink / raw) To: linux-arm-kernel Hi Joe, On Fri, Nov 13, 2015 at 8:52 AM, Joe Perches <joe@perches.com> wrote: > On Fri, 2015-11-13 at 08:37 +0100, Geert Uytterhoeven wrote: >> On Thu, Nov 12, 2015 at 10:03 PM, Arnd Bergmann <arnd@arndb.de> >> wrote: >> > 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)) >> > >> > This is a result of the type conversion rules in C, when we take >> > the >> > logical OR of multiple different types. In particular, we have >> > and unsigned long >> > >> > QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == >> > 0x0000000000000001ul >> > >> > and a signed int >> > >> > 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 >> > >> > which together gives a signed long value >> > >> > 0xffffffffc0000001l >> > >> > and when this is passed into a function that takes an unsigned int >> > type, >> > gcc warns about the signed overflow and the loss of the upper 32 >> > -bits that >> > are all ones. >> > >> > This patch adds 'ul' type modifiers to the literal numbers passed >> > in >> > here, so now the expression remains an 'unsigned long' with the >> > upper >> > bits all zero, and that avoids the signed overflow and the warning. >> >> FWIW, the 64-bitness of BIT() on 64-bit platforms is also causing >> subtle >> warnings in other places, e.g. when inverting them to create bit >> mask, cfr. >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi >> t/?id=a9efeca613a8fe5281d7c91f5c8c9ea46f2312f6 > > I still think specific length BIT macros > can be useful. > > https://lkml.org/lkml/2015/10/16/852 Yeah! I only recently started liking the BIT() macro (before I preferred hex, too). Perhaps because Renesas datasheets use bit numbers all over the place ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] stmmac: avoid ipq806x constant overflow warning @ 2015-11-13 8:00 ` Geert Uytterhoeven 0 siblings, 0 replies; 19+ messages in thread From: Geert Uytterhoeven @ 2015-11-13 8:00 UTC (permalink / raw) To: Joe Perches Cc: Arnd Bergmann, linux-arm-kernel, David Miller, netdev, mathieu, linux-kernel, Giuseppe Cavallaro Hi Joe, On Fri, Nov 13, 2015 at 8:52 AM, Joe Perches <joe@perches.com> wrote: > On Fri, 2015-11-13 at 08:37 +0100, Geert Uytterhoeven wrote: >> On Thu, Nov 12, 2015 at 10:03 PM, Arnd Bergmann <arnd@arndb.de> >> wrote: >> > 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)) >> > >> > This is a result of the type conversion rules in C, when we take >> > the >> > logical OR of multiple different types. In particular, we have >> > and unsigned long >> > >> > QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == >> > 0x0000000000000001ul >> > >> > and a signed int >> > >> > 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 >> > >> > which together gives a signed long value >> > >> > 0xffffffffc0000001l >> > >> > and when this is passed into a function that takes an unsigned int >> > type, >> > gcc warns about the signed overflow and the loss of the upper 32 >> > -bits that >> > are all ones. >> > >> > This patch adds 'ul' type modifiers to the literal numbers passed >> > in >> > here, so now the expression remains an 'unsigned long' with the >> > upper >> > bits all zero, and that avoids the signed overflow and the warning. >> >> FWIW, the 64-bitness of BIT() on 64-bit platforms is also causing >> subtle >> warnings in other places, e.g. when inverting them to create bit >> mask, cfr. >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi >> t/?id=a9efeca613a8fe5281d7c91f5c8c9ea46f2312f6 > > I still think specific length BIT macros > can be useful. > > https://lkml.org/lkml/2015/10/16/852 Yeah! I only recently started liking the BIT() macro (before I preferred hex, too). Perhaps because Renesas datasheets use bit numbers all over the place ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2015-11-13 8:00 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.