1. 02 4月, 2016 9 次提交
    • M
      net: mvneta: fix changing MTU when using per-cpu processing · db5dd0db
      Marcin Wojtas 提交于
      After enabling per-cpu processing it appeared that under heavy load
      changing MTU can result in blocking all port's interrupts and
      transmitting data is not possible after the change.
      
      This commit fixes above issue by disabling percpu interrupts for the
      time, when TXQs and RXQs are reconfigured.
      Signed-off-by: NMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      db5dd0db
    • D
      Merge branch 'stmmac-fixes' · ce2a04c1
      David S. Miller 提交于
      Giuseppe Cavallaro says:
      
      ====================
      stmmac MDIO and normal descr fixes
      
      This patch series is to fix the problems below and recently debugged
      in this mailing list:
      
      o to fix a problem for the HW where the normal descriptor
      o to fix the mdio registration according to the different
        platform configurations
      
      I am resending all the patches again: built on top of net.git repo.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce2a04c1
    • G
      stmmac: fix MDIO settings · a7657f12
      Giuseppe CAVALLARO 提交于
      Initially the phy_bus_name was added to manipulate the
      driver name but it was recently just used to manage the
      fixed-link and then to take some decision at run-time.
      So the patch uses the is_pseudo_fixed_link and removes
      the phy_bus_name variable not necessary anymore.
      
      The driver can manage the mdio registration by using phy-handle,
      dwmac-mdio and own parameter e.g. snps,phy-addr.
      This patch takes care about all these possible configurations
      and fixes the mdio registration in case of there is a real
      transceiver or a switch (that needs to be managed by using
      fixed-link).
      Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Reviewed-by: NAndreas Färber <afaerber@suse.de>
      Tested-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
      Cc: Gabriel Fernandez <gabriel.fernandez@linaro.org>
      Cc: Dinh Nguyen <dinh.linux@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Phil Reid <preid@electromag.com.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a7657f12
    • G
      Revert "stmmac: Fix 'eth0: No PHY found' regression" · d7e944c8
      Giuseppe CAVALLARO 提交于
      This reverts commit 88f8b1bb.
      due to problems on GeekBox and Banana Pi M1 board when
      connected to a real transceiver instead of a switch via
      fixed-link.
      Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Cc: Gabriel Fernandez <gabriel.fernandez@linaro.org>
      Cc: Andreas Färber <afaerber@suse.de>
      Cc: Frank Schäfer <fschaefer.oss@googlemail.com>
      Cc: Dinh Nguyen <dinh.linux@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d7e944c8
    • G
      stmmac: fix TX normal DESC · a00e3ab6
      Giuseppe CAVALLARO 提交于
      This patch fixs a regression raised when test on chips that use
      the normal descriptor layout. In fact, no len bits were set for
      the TDES1 and no OWN bit inside the TDES0.
      Signed-off-by: NGiuseppe CAVALLARO <peppe.cavallaro@st.com>
      Tested-by: NAndreas Färber <afaerber@suse.de>
      Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a00e3ab6
    • J
      net: mvneta: use cache_line_size() to get cacheline size · c66e98c9
      Jisheng Zhang 提交于
      L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size
      to determine the cacheline size in runtime.
      Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
      Suggested-by: NMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c66e98c9
    • J
      net: mvpp2: use cache_line_size() to get cacheline size · 4a0a12d2
      Jisheng Zhang 提交于
      L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size
      to determine the cacheline size in runtime.
      Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
      Suggested-by: NMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a0a12d2
    • J
      net: mvpp2: fix maybe-uninitialized warning · d82b0c21
      Jisheng Zhang 提交于
      This is to fix the following maybe-uninitialized warning:
      
      drivers/net/ethernet/marvell/mvpp2.c:6007:18: warning: 'err' may be
      used uninitialized in this function [-Wmaybe-uninitialized]
      Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d82b0c21
    • D
      tun, bpf: fix suspicious RCU usage in tun_{attach, detach}_filter · 5a5abb1f
      Daniel Borkmann 提交于
      Sasha Levin reported a suspicious rcu_dereference_protected() warning
      found while fuzzing with trinity that is similar to this one:
      
        [   52.765684] net/core/filter.c:2262 suspicious rcu_dereference_protected() usage!
        [   52.765688] other info that might help us debug this:
        [   52.765695] rcu_scheduler_active = 1, debug_locks = 1
        [   52.765701] 1 lock held by a.out/1525:
        [   52.765704]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff816a64b7>] rtnl_lock+0x17/0x20
        [   52.765721] stack backtrace:
        [   52.765728] CPU: 1 PID: 1525 Comm: a.out Not tainted 4.5.0+ #264
        [...]
        [   52.765768] Call Trace:
        [   52.765775]  [<ffffffff813e488d>] dump_stack+0x85/0xc8
        [   52.765784]  [<ffffffff810f2fa5>] lockdep_rcu_suspicious+0xd5/0x110
        [   52.765792]  [<ffffffff816afdc2>] sk_detach_filter+0x82/0x90
        [   52.765801]  [<ffffffffa0883425>] tun_detach_filter+0x35/0x90 [tun]
        [   52.765810]  [<ffffffffa0884ed4>] __tun_chr_ioctl+0x354/0x1130 [tun]
        [   52.765818]  [<ffffffff8136fed0>] ? selinux_file_ioctl+0x130/0x210
        [   52.765827]  [<ffffffffa0885ce3>] tun_chr_ioctl+0x13/0x20 [tun]
        [   52.765834]  [<ffffffff81260ea6>] do_vfs_ioctl+0x96/0x690
        [   52.765843]  [<ffffffff81364af3>] ? security_file_ioctl+0x43/0x60
        [   52.765850]  [<ffffffff81261519>] SyS_ioctl+0x79/0x90
        [   52.765858]  [<ffffffff81003ba2>] do_syscall_64+0x62/0x140
        [   52.765866]  [<ffffffff817d563f>] entry_SYSCALL64_slow_path+0x25/0x25
      
      Same can be triggered with PROVE_RCU (+ PROVE_RCU_REPEATEDLY) enabled
      from tun_attach_filter() when user space calls ioctl(tun_fd, TUN{ATTACH,
      DETACH}FILTER, ...) for adding/removing a BPF filter on tap devices.
      
      Since the fix in f91ff5b9 ("net: sk_{detach|attach}_filter() rcu
      fixes") sk_attach_filter()/sk_detach_filter() now dereferences the
      filter with rcu_dereference_protected(), checking whether socket lock
      is held in control path.
      
      Since its introduction in 99405162 ("tun: socket filter support"),
      tap filters are managed under RTNL lock from __tun_chr_ioctl(). Thus the
      sock_owned_by_user(sk) doesn't apply in this specific case and therefore
      triggers the false positive.
      
      Extend the BPF API with __sk_attach_filter()/__sk_detach_filter() pair
      that is used by tap filters and pass in lockdep_rtnl_is_held() for the
      rcu_dereference_protected() checks instead.
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a5abb1f
  2. 01 4月, 2016 7 次提交
  3. 31 3月, 2016 12 次提交
  4. 30 3月, 2016 11 次提交
  5. 29 3月, 2016 1 次提交
    • B
      qmi_wwan: add "D-Link DWM-221 B1" device id · e84810c7
      Bjørn Mork 提交于
      Thomas reports:
      "Windows:
      
      00 diagnostics
      01 modem
      02 at-port
      03 nmea
      04 nic
      
      Linux:
      
      T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2001 ProdID=7e19 Rev=02.32
      S:  Manufacturer=Mobile Connect
      S:  Product=Mobile Connect
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage"
      Reported-by: NThomas Schäfer <tschaefer@t-online.de>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e84810c7