These are all fixes for relatively harmless bugs that showed up
in my randconfig testing, so they should not be needed for v4.5
but get merged into net-next.
I've managed to address all 'uninitialized variable' warnings that
I get in ARM randconfig kernels now, this series includes the
last five I got in network drivers. They are often really annoying
warnings but when we get new ones, they often are about actual
bugs in corner cases, so I'm trying hard to eliminate the false
positives here to get people to pay attention to added warnings.
I've recently tried building with an older gcc and found tons more
that are all bogus, this series only addresses the ones that
gcc-5.2 finds.
Arnd Bergmann (9):
net: davinci_cpdma: use dma_addr_t for DMA address
net: hp100: remove unnecessary #ifdefs
net: bgmac: clarify CONFIG_BCMA dependency
net: moxart: use correct accessors for DMA memory
net: fddi/defxx: avoid warning about uninitialized variable use
net: vxge: avoid unused function warnings
net: macb: avoid uninitialized variables
net: nb8800: avoid uninitialized variable warning
net: tg3: avoid uninitialized variable warning
drivers/net/ethernet/aurora/nb8800.c | 4 +--
drivers/net/ethernet/broadcom/Kconfig | 5 ++-
drivers/net/ethernet/broadcom/tg3.c | 2 +-
drivers/net/ethernet/cadence/macb.c | 1 +
drivers/net/ethernet/hp/hp100.c | 18 -----------
drivers/net/ethernet/moxa/moxart_ether.c | 42 ++++++++++++++++----------
drivers/net/ethernet/moxa/moxart_ether.h | 4 +--
drivers/net/ethernet/neterion/vxge/vxge-main.c | 31 ++++++++-----------
drivers/net/ethernet/ti/davinci_cpdma.c | 12 ++++----
drivers/net/fddi/defxx.c | 5 +++
10 files changed, 59 insertions(+), 65 deletions(-)
--
2.7.0
The davinci_cpdma mixes up physical addresses as seen from the CPU
and DMA addresses as seen from a DMA master, since it can operate
on both normal memory or an on-chip buffer. If dma_addr_t is
different from phys_addr_t, this means we get a compile-time warning
about the type mismatch:
ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
ethernet/ti/davinci_cpdma.c:182:48: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
In file included from ethernet/ti/davinci_cpdma.c:21:0:
dma-mapping.h:398:21: note: expected 'dma_addr_t * {aka long long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
static inline void *dma_alloc_coherent(struct device *dev, size_t size,
This slightly restructures the code so the address we use for
mapping RAM into a DMA address is always a dma_addr_t, avoiding
the warning. The code is correct even if both types are 32-bit
because the DMA master in this device only supports 32-bit addressing
anyway, independent of the types that are used.
We still assign this value to pool->phys, and that is wrong if
the driver is ever used with an IOMMU, but that value appears to
be never used, so there is no problem really. I've added a couple
of comments about where we do things that are slightly violating
the API.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/ti/davinci_cpdma.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
@@ -176,13 +176,13 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, u32 hw_addr,if(phys){pool->phys=phys;-pool->iomap=ioremap(phys,size);+pool->iomap=ioremap(phys,size);/* should be memremap? */pool->hw_addr=hw_addr;}else{-pool->cpumap=dma_alloc_coherent(dev,size,&pool->phys,+pool->cpumap=dma_alloc_coherent(dev,size,&pool->hw_addr,GFP_KERNEL);-pool->iomap=pool->cpumap;-pool->hw_addr=pool->phys;+pool->iomap=(void__iomem__force*)pool->cpumap;+pool->phys=pool->hw_addr;/* assumes no IOMMU, don't use this value */}if(pool->iomap)
Building the hp100 ethernet driver causes warnings when both the PCI
and EISA drivers are disabled:
ethernet/hp/hp100.c: In function 'hp100_module_init':
ethernet/hp/hp100.c:3047:2: warning: label 'out3' defined but not used [-Wunused-label]
ethernet/hp/hp100.c: At top level:
ethernet/hp/hp100.c:2828:13: warning: 'cleanup_dev' defined but not used [-Wunused-function]
We can easily avoid the warnings and make the driver look slightly
nicer by removing the #ifdefs that check for the CONFIG_PCI and
CONFIG_EISA, as all the registration functions are designed to
have no effect when the buses are disabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/hp/hp100.c | 18 ------------------
1 file changed, 18 deletions(-)
The bgmac driver depends on BCMA_HOST_SOC, which is only used
when CONFIG_BCMA is enabled. However, it is a bool option and can
be set when CONFIG_BCMA=m, and then bgmac can be built-in, leading
to an obvious link error:
drivers/built-in.o: In function `bgmac_init':
:(.init.text+0x7f2c): undefined reference to `__bcma_driver_register'
drivers/built-in.o: In function `bgmac_exit':
:(.exit.text+0x110a): undefined reference to `bcma_driver_unregister'
To avoid this case, we need to depend on both BCMA and BCMA_SOC,
as this patch does. I'm also trying to make the dependency more
readable by splitting it into three lines, and adding a COMPILE_TEST
alternative so we can test-build it in all configurations that
support BCMA.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/broadcom/Kconfig | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
The moxart ethernet driver confuses coherent DMA buffers with
MMIO registers.
moxart_ether.c: In function 'moxart_mac_setup_desc_ring':
moxart_ether.c:146:428: error: passing argument 1 of '__fswab32' makes integer from pointer without a cast [-Werror=int-conversion]
moxart_ether.c:74:39: warning: incorrect type in argument 3 (different address spaces)
moxart_ether.c:74:39: expected void *cpu_addr
moxart_ether.c:74:39: got void [noderef] <asn:2>*tx_desc_base
This leaves the basic logic alone and uses normal pointers for
the virtual address of the descriptor. As we cannot use readl/writel
to access them, we also introduce our own moxart_desc_read
moxart_desc_write helpers that perform the same endianess swap
as the original code, but without the extra barriers and address
space conversion.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/moxa/moxart_ether.c | 42 ++++++++++++++++++++------------
drivers/net/ethernet/moxa/moxart_ether.h | 4 +--
2 files changed, 28 insertions(+), 18 deletions(-)
When CONFIG_PCI_MSI is disabled, we get warnings about unused functions
in the vxge driver:
drivers/net/ethernet/neterion/vxge/vxge-main.c:2121:13: warning: 'adaptive_coalesce_tx_interrupts' defined but not used [-Wunused-function]
drivers/net/ethernet/neterion/vxge/vxge-main.c:2149:13: warning: 'adaptive_coalesce_rx_interrupts' defined but not used [-Wunused-function]
We could add another #ifdef here, but it's nicer to avoid those warnings
for good by converting the existing #ifdef to if(IS_ENABLED()), which has
the same effect but provides better compile-time coverage in general,
and lets the compiler understand better when the function is intentionally
unused.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/neterion/vxge/vxge-main.c | 31 ++++++++++----------------
1 file changed, 12 insertions(+), 19 deletions(-)
@@ -2475,7 +2469,7 @@ static int vxge_add_isr(struct vxgedev *vdev)vdev->config.intr_type=INTA;}-if(vdev->config.intr_type==MSI_X){+if(IS_ENABLED(CONFIG_PCI_MSI)&&vdev->config.intr_type==MSI_X){for(intr_idx=0;intr_idx<(vdev->no_of_vpath*VXGE_HW_VPATH_MSIX_ACTIVE);intr_idx++){
@@ -2576,9 +2570,8 @@ static int vxge_add_isr(struct vxgedev *vdev)vdev->vxge_entries[intr_cnt].in_use=1;vdev->vxge_entries[intr_cnt].arg=&vdev->vpaths[0];}-INTA_MODE:-#endif+INTA_MODE:if(vdev->config.intr_type==INTA){snprintf(vdev->desc[0],VXGE_INTR_STRLEN,"%s:vxge:INTA",vdev->ndev->name);
@@ -3889,12 +3882,12 @@ static void vxge_device_config_init(struct vxge_hw_device_config *device_config,if(max_mac_vpath>VXGE_MAX_MAC_ADDR_COUNT)max_mac_vpath=VXGE_MAX_MAC_ADDR_COUNT;-#ifndef CONFIG_PCI_MSI-vxge_debug_init(VXGE_ERR,-"%s: This Kernel does not support "-"MSI-X. Defaulting to INTA",VXGE_DRIVER_NAME);-*intr_type=INTA;-#endif+if(!IS_ENABLED(CONFIG_PCI_MSI)){+vxge_debug_init(VXGE_ERR,+"%s: This Kernel does not support "+"MSI-X. Defaulting to INTA",VXGE_DRIVER_NAME);+*intr_type=INTA;+}/* Configure whether MSI-X or IRQL. */switch(*intr_type){
The macb_clk_init function returns three clock pointers, unless
the it fails to get the first ones. We correctly handle the
failure case by propagating the error from macb_probe, but
gcc does not realize this and incorrectly warns about a later
use of those:
In file included from /git/arm-soc/drivers/net/ethernet/cadence/macb.c:12:0:
drivers/net/ethernet/cadence/macb.c: In function 'macb_probe':
include/linux/clk.h:484:2: error: 'tx_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
clk_disable(clk);
^
drivers/net/ethernet/cadence/macb.c:2822:28: note: 'tx_clk' was declared here
struct clk *pclk, *hclk, *tx_clk;
^
In file included from /git/arm-soc/drivers/net/ethernet/cadence/macb.c:12:0:
include/linux/clk.h:484:2: error: 'hclk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
clk_disable(clk);
^
drivers/net/ethernet/cadence/macb.c:2822:21: note: 'hclk' was declared here
struct clk *pclk, *hclk, *tx_clk;
^
This shuts up the misleading warnings by ensuring that the
macb_clk_init() always stores something into all three pointers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/cadence/macb.c | 1 +
1 file changed, 1 insertion(+)
The nb8800_poll() function initializes the 'next' variable in the
loop looking for new input data. We know this will be called at
least once because 'budget' is a guaranteed to be a positive number
when we enter the function, but the compiler doesn't know that
and warns when the variable is used later:
drivers/net/ethernet/aurora/nb8800.c: In function 'nb8800_poll':
drivers/net/ethernet/aurora/nb8800.c:350:21: warning: 'next' may be used uninitialized in this function [-Wmaybe-uninitialized]
Changing the 'while() {}' loop to 'do {} while()' makes it obvious
to the compiler what is going on so it no longer warns.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/aurora/nb8800.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
The tg3_set_eeprom() function correctly initializes the 'start' variable,
but gcc generates a false warning:
drivers/net/ethernet/broadcom/tg3.c: In function 'tg3_set_eeprom':
drivers/net/ethernet/broadcom/tg3.c:12057:4: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized]
I have not come up with a way to restructure the code in a way that
avoids the warning without making it less readable, so this adds an
initialization for the declaration to shut up that warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/broadcom/tg3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The defxx driver can be configured for different kinds of buses,
and appears to be handling this correctly, but the compiler cannot
see how it always initializes the bar_start and bar_length
fields it uses depending on the configured bus, so we get a warning
with recent gcc versions:
fddi/defxx.c: In function 'dfx_pci_unregister':
fddi/defxx.c:3726:3: warning: 'bar_len' may be used uninitialized in this function [-Wmaybe-uninitialized]
release_mem_region(bar_start[0], bar_len[0]);
fddi/defxx.c:3701:18: note: 'bar_len' was declared here
resource_size_t bar_len[3]; /* resource lengths */
fddi/defxx.c:3726:3: warning: 'bar_start' may be used uninitialized in this function [-Wmaybe-uninitialized]
release_mem_region(bar_start[0], bar_len[0]);
fddi/defxx.c:3700:18: note: 'bar_start' was declared here
resource_size_t bar_start[3]; /* pointers to ports */
^
fddi/defxx.c: In function 'dfx_pci_register':
fddi/defxx.c:617:18: warning: 'bar_len' may be used uninitialized in this function [-Wmaybe-uninitialized]
bp->base.mem = ioremap_nocache(bar_start[0], bar_len[0]);
fddi/defxx.c:537:18: note: 'bar_len' was declared here
resource_size_t bar_len[3]; /* resource length */
fddi/defxx.c:1125:2: warning: 'bar_start' may be used uninitialized in this function [-Wmaybe-uninitialized]
pr_info("%s: %s at %s addr = 0x%llx, IRQ = %d, Hardware addr = %pMF\n",
fddi/defxx.c:536:18: note: 'bar_start' was declared here
resource_size_t bar_start[3]; /* pointers to ports */
This adds code to ensure that the BAR values are initialized
even in the impossible case when a device gets probed that
does not belong to any bus. This shuts up the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/fddi/defxx.c | 5 +++++
1 file changed, 5 insertions(+)
From: Maciej W. Rozycki <hidden> Date: 2016-01-27 15:15:31
On Wed, 27 Jan 2016, Arnd Bergmann wrote:
This adds code to ensure that the BAR values are initialized
even in the impossible case when a device gets probed that
does not belong to any bus. This shuts up the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/fddi/defxx.c | 5 +++++
1 file changed, 5 insertions(+)
NAK, fixed already, commit 62f2aaabcf41 ("defxx: fix build warning").
Thanks for looking into this problem though, always welcome!
Maciej
From: Nicolas Ferre <hidden> Date: 2016-01-27 15:51:44
Le 27/01/2016 15:04, Arnd Bergmann a écrit :
The macb_clk_init function returns three clock pointers, unless
the it fails to get the first ones. We correctly handle the
failure case by propagating the error from macb_probe, but
gcc does not realize this and incorrectly warns about a later
use of those:
In file included from /git/arm-soc/drivers/net/ethernet/cadence/macb.c:12:0:
drivers/net/ethernet/cadence/macb.c: In function 'macb_probe':
include/linux/clk.h:484:2: error: 'tx_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
clk_disable(clk);
^
drivers/net/ethernet/cadence/macb.c:2822:28: note: 'tx_clk' was declared here
struct clk *pclk, *hclk, *tx_clk;
^
In file included from /git/arm-soc/drivers/net/ethernet/cadence/macb.c:12:0:
include/linux/clk.h:484:2: error: 'hclk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
clk_disable(clk);
^
drivers/net/ethernet/cadence/macb.c:2822:21: note: 'hclk' was declared here
struct clk *pclk, *hclk, *tx_clk;
^
This shuts up the misleading warnings by ensuring that the
macb_clk_init() always stores something into all three pointers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Okay Arnd, thanks!
Acked-by: Nicolas Ferre <redacted>
From: Nicolas Ferre <hidden> Date: 2016-01-27 16:04:59
Le 27/01/2016 16:51, Nicolas Ferre a écrit :
Le 27/01/2016 15:04, Arnd Bergmann a écrit :
quoted
The macb_clk_init function returns three clock pointers, unless
the it fails to get the first ones. We correctly handle the
failure case by propagating the error from macb_probe, but
gcc does not realize this and incorrectly warns about a later
use of those:
In file included from /git/arm-soc/drivers/net/ethernet/cadence/macb.c:12:0:
drivers/net/ethernet/cadence/macb.c: In function 'macb_probe':
include/linux/clk.h:484:2: error: 'tx_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
clk_disable(clk);
^
drivers/net/ethernet/cadence/macb.c:2822:28: note: 'tx_clk' was declared here
struct clk *pclk, *hclk, *tx_clk;
^
In file included from /git/arm-soc/drivers/net/ethernet/cadence/macb.c:12:0:
include/linux/clk.h:484:2: error: 'hclk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
clk_disable(clk);
^
drivers/net/ethernet/cadence/macb.c:2822:21: note: 'hclk' was declared here
struct clk *pclk, *hclk, *tx_clk;
^
This shuts up the misleading warnings by ensuring that the
macb_clk_init() always stores something into all three pointers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Okay Arnd, thanks!
Acked-by: Nicolas Ferre <redacted>
Oh, crap: actually this warning has just been fixed by Sudip Mukherjee
and is already queued by David here:
https://patchwork.ozlabs.org/patch/572610/
So, sorry, I've shot too fast: NACK...
Bye,
The bgmac driver depends on BCMA_HOST_SOC, which is only used
when CONFIG_BCMA is enabled. However, it is a bool option and can
be set when CONFIG_BCMA=m, and then bgmac can be built-in, leading
to an obvious link error:
drivers/built-in.o: In function `bgmac_init':
:(.init.text+0x7f2c): undefined reference to `__bcma_driver_register'
drivers/built-in.o: In function `bgmac_exit':
:(.exit.text+0x110a): undefined reference to `bcma_driver_unregister'
To avoid this case, we need to depend on both BCMA and BCMA_SOC,
as this patch does. I'm also trying to make the dependency more
readable by splitting it into three lines, and adding a COMPILE_TEST
alternative so we can test-build it in all configurations that
support BCMA.
It wasn't immediately clear to me from the above why you added the
select on FIXED_PHY.
P.
The bgmac driver depends on BCMA_HOST_SOC, which is only used
when CONFIG_BCMA is enabled. However, it is a bool option and can
be set when CONFIG_BCMA=m, and then bgmac can be built-in, leading
to an obvious link error:
drivers/built-in.o: In function `bgmac_init':
:(.init.text+0x7f2c): undefined reference to `__bcma_driver_register'
drivers/built-in.o: In function `bgmac_exit':
:(.exit.text+0x110a): undefined reference to `bcma_driver_unregister'
To avoid this case, we need to depend on both BCMA and BCMA_SOC,
as this patch does. I'm also trying to make the dependency more
readable by splitting it into three lines, and adding a COMPILE_TEST
alternative so we can test-build it in all configurations that
support BCMA.
It wasn't immediately clear to me from the above why you added the
select on FIXED_PHY.
Right, I'll resend the patch with improved changelog. This series
is mostly patches for old and rare randconfig bugs, so I had built
thousands of configurations and fixed up everything until new warnings
or errors kept coming up. The FIXED_PHY error came up in the same
driver so I merged the two patches but did not notice how the changelog
failed to explain it.
Thanks,
Arnd
From: David Laight <hidden> Date: 2016-01-28 12:39:22
From: Arnd Bergmann
Sent: 27 January 2016 14:05
The moxart ethernet driver confuses coherent DMA buffers with
MMIO registers.
moxart_ether.c: In function 'moxart_mac_setup_desc_ring':
moxart_ether.c:146:428: error: passing argument 1 of '__fswab32' makes integer from pointer without a
cast [-Werror=int-conversion]
moxart_ether.c:74:39: warning: incorrect type in argument 3 (different address spaces)
moxart_ether.c:74:39: expected void *cpu_addr
moxart_ether.c:74:39: got void [noderef] <asn:2>*tx_desc_base
This leaves the basic logic alone and uses normal pointers for
the virtual address of the descriptor. As we cannot use readl/writel
to access them, we also introduce our own moxart_desc_read
moxart_desc_write helpers that perform the same endianess swap
as the original code, but without the extra barriers and address
space conversion.
I'm pretty sure you need to add some explicit barriers:
From: Sergei Shtylyov <hidden> Date: 2016-01-28 13:27:46
Hello.
On 1/27/2016 5:04 PM, Arnd Bergmann wrote:
The macb_clk_init function returns three clock pointers, unless
the it fails to get the first ones. We correctly handle the
s/the//.
failure case by propagating the error from macb_probe, but
gcc does not realize this and incorrectly warns about a later
use of those:
In file included from /git/arm-soc/drivers/net/ethernet/cadence/macb.c:12:0:
drivers/net/ethernet/cadence/macb.c: In function 'macb_probe':
Hm, didn't these 2 lines get swapped by chance?
include/linux/clk.h:484:2: error: 'tx_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
clk_disable(clk);
^
drivers/net/ethernet/cadence/macb.c:2822:28: note: 'tx_clk' was declared here
struct clk *pclk, *hclk, *tx_clk;
^
In file included from /git/arm-soc/drivers/net/ethernet/cadence/macb.c:12:0:
include/linux/clk.h:484:2: error: 'hclk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
clk_disable(clk);
^
drivers/net/ethernet/cadence/macb.c:2822:21: note: 'hclk' was declared here
struct clk *pclk, *hclk, *tx_clk;
^
This shuts up the misleading warnings by ensuring that the
macb_clk_init() always stores something into all three pointers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
On Wednesday 27 January 2016 17:04:47 Nicolas Ferre wrote:
quoted
Okay Arnd, thanks!
Acked-by: Nicolas Ferre <redacted>
Oh, crap: actually this warning has just been fixed by Sudip Mukherjee
and is already queued by David here:
https://patchwork.ozlabs.org/patch/572610/
So, sorry, I've shot too fast: NACK...
On Thursday 28 January 2016 12:36:19 David Laight wrote:
From: Arnd Bergmann
quoted
Sent: 27 January 2016 14:05
The moxart ethernet driver confuses coherent DMA buffers with
MMIO registers.
moxart_ether.c: In function 'moxart_mac_setup_desc_ring':
moxart_ether.c:146:428: error: passing argument 1 of '__fswab32' makes integer from pointer without a
cast [-Werror=int-conversion]
moxart_ether.c:74:39: warning: incorrect type in argument 3 (different address spaces)
moxart_ether.c:74:39: expected void *cpu_addr
moxart_ether.c:74:39: got void [noderef] <asn:2>*tx_desc_base
This leaves the basic logic alone and uses normal pointers for
the virtual address of the descriptor. As we cannot use readl/writel
to access them, we also introduce our own moxart_desc_read
moxart_desc_write helpers that perform the same endianess swap
as the original code, but without the extra barriers and address
space conversion.
I'm pretty sure you need to add some explicit barriers:
Those last two writes must happen in that order.
There may be others.
Makes sense. I looked at the ftmac100 driver, which is another driver
for the same hardware, and it's also missing barriers. We should
probably add them for both then.
I think for the SoC that uses this, a barrier() would be sufficient
because of the page flags that dma_alloc_coherent() uses on ARM for
non-coherent platforms, but to be on the safe side we need a full
rmb()/wmb(). Sending a version 2 now.
Arnd
On Thursday 28 January 2016 17:53:43 Arnd Bergmann wrote:
Makes sense. I looked at the ftmac100 driver, which is another driver
for the same hardware, and it's also missing barriers. We should
probably add them for both then.
Nevermind. That one has write barriers, but no read barriers. I'm assuming
that this intentional and won't follow up with another patch for ftmac100.
Arnd
These are all fixes for relatively harmless bugs that showed up
in my randconfig testing, so they should not be needed for v4.5
but get merged into net-next.
I've managed to address all 'uninitialized variable' warnings that
I get in ARM randconfig kernels now, this series includes the
last five I got in network drivers. They are often really annoying
warnings but when we get new ones, they often are about actual
bugs in corner cases, so I'm trying hard to eliminate the false
positives here to get people to pay attention to added warnings.
I've recently tried building with an older gcc and found tons more
that are all bogus, this series only addresses the ones that
gcc-5.2 finds.
Arnd I'm expecting a respin of this series to address with the
feedback you've been given.
Thanks.
These are all fixes for relatively harmless bugs that showed up
in my randconfig testing, so they should not be needed for v4.5
but get merged into net-next.
I've managed to address all 'uninitialized variable' warnings that
I get in ARM randconfig kernels now, this series includes the
last five I got in network drivers. They are often really annoying
warnings but when we get new ones, they often are about actual
bugs in corner cases, so I'm trying hard to eliminate the false
positives here to get people to pay attention to added warnings.
I've recently tried building with an older gcc and found tons more
that are all bogus, this series only addresses the ones that
gcc-5.2 finds.
Arnd I'm expecting a respin of this series to address with the
feedback you've been given.
Done. I wasn't sure if you planned to pick up the patches
individually, thanks for the clarification.
Arnd