| Message ID | 1453903507-3427225-1-git-send-email-arnd@arndb.de |
|---|---|
| Headers | show |
| Series | network driver fixes | expand |
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
[[PATCH 3/9] net: bgmac: clarify CONFIG_BCMA dependency] On 27/01/2016 (Wed 15:04) Arnd Bergmann wrote: > 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. -- > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/net/ethernet/broadcom/Kconfig | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig > index 8550df189ceb..19f7cd02e085 100644 > --- a/drivers/net/ethernet/broadcom/Kconfig > +++ b/drivers/net/ethernet/broadcom/Kconfig > @@ -151,8 +151,11 @@ config BNX2X_VXLAN > > config BGMAC > tristate "BCMA bus GBit core support" > - depends on BCMA_HOST_SOC && HAS_DMA && (BCM47XX || ARCH_BCM_5301X) > + depends on BCMA && BCMA_HOST_SOC > + depends on HAS_DMA > + depends on BCM47XX || ARCH_BCM_5301X || COMPILE_TEST > select PHYLIB > + select FIXED_PHY > ---help--- > This driver supports GBit MAC and BCM4706 GBit MAC cores on BCMA bus. > They can be found on BCM47xx SoCs and provide gigabit ethernet. > -- > 2.7.0 >
From: Arnd Bergmann <arnd@arndb.de> Date: Wed, 27 Jan 2016 15:04:50 +0100 > 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.
On Thursday 28 January 2016 16:14:13 David Miller wrote: > From: Arnd Bergmann <arnd@arndb.de> > Date: Wed, 27 Jan 2016 15:04:50 +0100 > > > 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