1. 19 11月, 2016 2 次提交
  2. 08 11月, 2016 2 次提交
  3. 13 10月, 2016 1 次提交
    • A
      tlan: avoid unused label with PCI=n · 1e09c106
      Arnd Bergmann 提交于
      While build testing with randconfig on x86, I ran into this warning
      that appears to have been around forever
      
      drivers/net/ethernet/ti/tlan.c: In function ‘tlan_probe1’:
      drivers/net/ethernet/ti/tlan.c:614:1: error: label ‘err_out’ defined but not used [-Werror=unused-label]
      
      This can be trivially avoided by just moving the label into the
      existing #ifdef.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e09c106
  4. 07 10月, 2016 1 次提交
  5. 05 9月, 2016 1 次提交
    • P
      net: ti: cpmac: Fix compiler warning due to type confusion · 2f5281ba
      Paul Burton 提交于
      cpmac_start_xmit() used the max() macro on skb->len (an unsigned int)
      and ETH_ZLEN (a signed int literal). This led to the following compiler
      warning:
      
        In file included from include/linux/list.h:8:0,
                         from include/linux/module.h:9,
                         from drivers/net/ethernet/ti/cpmac.c:19:
        drivers/net/ethernet/ti/cpmac.c: In function 'cpmac_start_xmit':
        include/linux/kernel.h:748:17: warning: comparison of distinct pointer
        types lacks a cast
          (void) (&_max1 == &_max2);  \
                         ^
        drivers/net/ethernet/ti/cpmac.c:560:8: note: in expansion of macro 'max'
          len = max(skb->len, ETH_ZLEN);
                ^
      
      On top of this, it assigned the result of the max() macro to a signed
      integer whilst all further uses of it result in it being cast to varying
      widths of unsigned integer.
      
      Fix this up by using max_t to ensure the comparison is performed as
      unsigned integers, and for consistency change the type of the len
      variable to unsigned int.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2f5281ba
  6. 27 8月, 2016 1 次提交
  7. 23 8月, 2016 5 次提交
  8. 11 8月, 2016 14 次提交
  9. 10 8月, 2016 1 次提交
    • G
      drivers: net: cpsw: fix kmemleak false-positive reports for sk buffers · 254a49d5
      Grygorii Strashko 提交于
      Kmemleak reports following false positive memory leaks for each sk
      buffers allocated by CPSW (__netdev_alloc_skb_ip_align()) in
      cpsw_ndo_open() and cpsw_rx_handler():
      
      unreferenced object 0xea915000 (size 2048):
        comm "systemd-network", pid 713, jiffies 4294938323 (age 102.180s)
        hex dump (first 32 bytes):
          00 58 91 ea ff ff ff ff ff ff ff ff ff ff ff ff  .X..............
          ff ff ff ff ff ff fd 0f 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<c0108680>] __kmalloc_track_caller+0x1a4/0x230
          [<c0529eb4>] __alloc_skb+0x68/0x16c
          [<c052c884>] __netdev_alloc_skb+0x40/0x104
          [<bf1ad29c>] cpsw_ndo_open+0x374/0x670 [ti_cpsw]
          [<c053c3d4>] __dev_open+0xb0/0x114
          [<c053c690>] __dev_change_flags+0x9c/0x14c
          [<c053c760>] dev_change_flags+0x20/0x50
          [<c054bdcc>] do_setlink+0x2cc/0x78c
          [<c054c358>] rtnl_setlink+0xcc/0x100
          [<c054b34c>] rtnetlink_rcv_msg+0x184/0x224
          [<c056467c>] netlink_rcv_skb+0xa8/0xc4
          [<c054b1c0>] rtnetlink_rcv+0x2c/0x34
          [<c0564018>] netlink_unicast+0x16c/0x1f8
          [<c0564498>] netlink_sendmsg+0x334/0x348
          [<c052015c>] sock_sendmsg+0x1c/0x2c
          [<c05213e0>] SyS_sendto+0xc0/0xe8
      
      unreferenced object 0xec861780 (size 192):
        comm "softirq", pid 0, jiffies 4294938759 (age 109.540s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 b0 5a ed 00 00 00 00 00 00 00 00  ......Z.........
        backtrace:
          [<c0107830>] kmem_cache_alloc+0x190/0x208
          [<c052c768>] __build_skb+0x30/0x98
          [<c052c8fc>] __netdev_alloc_skb+0xb8/0x104
          [<bf1abc54>] cpsw_rx_handler+0x68/0x1e4 [ti_cpsw]
          [<bf11aa30>] __cpdma_chan_free+0xa8/0xc4 [davinci_cpdma]
          [<bf11ab98>] __cpdma_chan_process+0x14c/0x16c [davinci_cpdma]
          [<bf11abfc>] cpdma_chan_process+0x44/0x5c [davinci_cpdma]
          [<bf1adc78>] cpsw_rx_poll+0x1c/0x9c [ti_cpsw]
          [<c0539180>] net_rx_action+0x1f0/0x2ec
          [<c003881c>] __do_softirq+0x134/0x258
          [<c0038a00>] do_softirq+0x68/0x70
          [<c0038adc>] __local_bh_enable_ip+0xd4/0xe8
          [<c0640994>] _raw_spin_unlock_bh+0x30/0x34
          [<c05f4e9c>] igmp6_group_added+0x4c/0x1bc
          [<c05f6600>] ipv6_dev_mc_inc+0x398/0x434
          [<c05dba74>] addrconf_dad_work+0x224/0x39c
      
      This happens because CPSW allocates SK buffers and then passes
      pointers on them in CPDMA where they stored in internal CPPI RAM
      (SRAM) which belongs to DEV MMIO space. Kmemleak does not scan IO
      memory and so reports memory leaks.
      
      Hence, mark allocated sk buffers as false positive explicitly.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      254a49d5
  10. 09 8月, 2016 1 次提交
  11. 02 8月, 2016 1 次提交
  12. 31 7月, 2016 3 次提交
  13. 26 7月, 2016 1 次提交
  14. 21 7月, 2016 1 次提交
  15. 20 7月, 2016 1 次提交
  16. 17 7月, 2016 1 次提交
  17. 16 7月, 2016 2 次提交
  18. 03 7月, 2016 1 次提交