1. 04 2月, 2016 12 次提交
  2. 30 1月, 2016 11 次提交
    • A
      net: tg3: avoid uninitialized variable warning · e434e041
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e434e041
    • A
      net: nb8800: avoid uninitialized variable warning · 8bdb2908
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NMans Rullgard <mans@mansr.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8bdb2908
    • A
      net: vxge: avoid unused function warnings · 57e7c8ce
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      57e7c8ce
    • A
      net: bgmac: clarify CONFIG_BCMA dependency · 1f820f53
      Arnd Bergmann 提交于
      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.
      
      The added dependency on FIXED_PHY addresses a related issue where
      we cannot call fixed_phy_register() when CONFIG_FIXED_PHY=m and
      CONFIG_BGMAC=y.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f820f53
    • A
      net: hp100: remove unnecessary #ifdefs · 747a1127
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      747a1127
    • A
      net: davinci_cpdma: use dma_addr_t for DMA address · 84092996
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84092996
    • A
      net: moxart: use correct accessors for DMA memory · 59a557be
      Arnd Bergmann 提交于
      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 address space conversion.
      
      The barriers are made explicit here where needed: Even in the worst-case
      scenario, we just have to use a rmb() after checking ownership so
      we don't read any input data before we are sure it is value, and we
      use wmb() before transferring ownership back to the device.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59a557be
    • M
      bnxt_en: Fix crash in bnxt_free_tx_skbs() during tx timeout. · d612a579
      Michael Chan 提交于
      The ring index j is not wrapped properly at the end of the ring, causing
      it to reference pointers past the end of the ring.  For proper loop
      termination and to access the ring properly, we need to increment j and
      mask it before referencing the ring entry.
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d612a579
    • M
      bnxt_en: Exclude rx_drop_pkts hw counter from the stack's rx_dropped counter. · 8a4d4c8d
      Michael Chan 提交于
      This hardware counter is misleading as it counts dropped packets that
      don't match the hardware filters for unicast/broadcast/multicast.  We
      will still report this counter in ethtool -S for diagnostics purposes.
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a4d4c8d
    • P
      bnxt_en: Ring free response from close path should use completion ring · 74608fc9
      Prashant Sreedharan 提交于
      Use completion ring for ring free response from firmware.  The response
      will be the last entry in the ring and we can free the ring after getting
      the response.  This will guarantee no spurious DMA to freed memory.
      Signed-off-by: NPrashant Sreedharan <prashant@broadcom.com>
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      74608fc9
    • K
      net: cavium: liquidio: use helpers ns_to_timespec64() · 286af315
      Kefeng Wang 提交于
      Convert the driver to use ns_to_timespec64() to keep consistency
      with timespec64_to_ns() instead of open coding the same logic.
      Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      286af315
  3. 29 1月, 2016 14 次提交
  4. 26 1月, 2016 3 次提交
    • A
      net: i40e: shut up uninitialized variable warnings · 79febbc1
      Arnd Bergmann 提交于
      intel/i40e/i40e_txrx.c: In function 'i40e_xmit_frame_ring':
      intel/i40e/i40e_txrx.c:2367:20: error: 'oiph' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      intel/i40e/i40e_txrx.c:2317:16: note: 'oiph' was declared here
      intel/i40e/i40e_txrx.c:2367:17: error: 'oudph' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      intel/i40e/i40e_txrx.c:2316:17: note: 'oudph' was declared here
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      79febbc1
    • E
      i40e: fix build warnings · 5cae7615
      Eric Dumazet 提交于
      Fixes following build warnings :
      
      drivers/net/ethernet/intel/i40e/i40e_main.c:7057:13: warning:
      'i40e_sync_udp_filters_subtask' defined but not used [-Wunused-function]
      drivers/net/ethernet/intel/i40e/i40e_main.c:8524:13: warning:
      'i40e_add_vxlan_port' defined but not used [-Wunused-function]
      drivers/net/ethernet/intel/i40e/i40e_main.c:8569:13: warning:
      'i40e_del_vxlan_port' defined but not used [-Wunused-function]
      drivers/net/ethernet/intel/i40e/i40e_main.c:8604:13: warning:
      'i40e_add_geneve_port' defined but not used [-Wunused-function]
      drivers/net/ethernet/intel/i40e/i40e_main.c:8651:13: warning:
      'i40e_del_geneve_port' defined but not used [-Wunused-function]
      
      Fixes: 6a899024 ("i40e: geneve tunnel offload support")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5cae7615
    • J
      net: fec: use CONFIG_ARM instead of CONFIG_ARCH_MXC/SOC_IMX28 · 05f3b50e
      Johannes Berg 提交于
      As Arnd Bergmann points out, using CONFIG_ARCH_MXC and/or SOC_IMX28
      is wrong if some other ARM platform uses this device - the operation
      of the driver would depend on an unrelated ARM platform that might
      or might not be set for multi-platform kernels.
      
      Prior to my previous patch, any other platforms using it would have
      been broken already due to having the cbd_datlen/cbd_sc fields in
      the wrong order, but byte ordering correctly, so no such platforms
      can exist and work today.
      
      In any case, it seems likely that only Freescale SoCs use this part,
      and those are little-endian on ARM, so CONFIG_ARM is safe for them.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05f3b50e