1. 01 Apr, 2016 9 commits
    • Marcin Wojtas's avatar
      net: mvneta: fix changing MTU when using per-cpu processing · db5dd0db
      Marcin Wojtas authored
      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: default avatarMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db5dd0db
    • David S. Miller's avatar
      Merge branch 'stmmac-fixes' · ce2a04c1
      David S. Miller authored
      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: default avatarDavid S. Miller <davem@davemloft.net>
      ce2a04c1
    • Giuseppe CAVALLARO's avatar
      stmmac: fix MDIO settings · a7657f12
      Giuseppe CAVALLARO authored
      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: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Reviewed-by: default avatarAndreas Färber <afaerber@suse.de>
      Tested-by: default avatarFrank 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: default avatarDavid S. Miller <davem@davemloft.net>
      a7657f12
    • Giuseppe CAVALLARO's avatar
      Revert "stmmac: Fix 'eth0: No PHY found' regression" · d7e944c8
      Giuseppe CAVALLARO authored
      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: default avatarGiuseppe 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: default avatarDavid S. Miller <davem@davemloft.net>
      d7e944c8
    • Giuseppe CAVALLARO's avatar
      stmmac: fix TX normal DESC · a00e3ab6
      Giuseppe CAVALLARO authored
      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: default avatarGiuseppe CAVALLARO <peppe.cavallaro@st.com>
      Tested-by: default avatarAndreas Färber <afaerber@suse.de>
      Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a00e3ab6
    • Jisheng Zhang's avatar
      net: mvneta: use cache_line_size() to get cacheline size · c66e98c9
      Jisheng Zhang authored
      L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size
      to determine the cacheline size in runtime.
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Suggested-by: default avatarMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c66e98c9
    • Jisheng Zhang's avatar
      net: mvpp2: use cache_line_size() to get cacheline size · 4a0a12d2
      Jisheng Zhang authored
      L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size
      to determine the cacheline size in runtime.
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Suggested-by: default avatarMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a0a12d2
    • Jisheng Zhang's avatar
      net: mvpp2: fix maybe-uninitialized warning · d82b0c21
      Jisheng Zhang authored
      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: default avatarJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d82b0c21
    • Daniel Borkmann's avatar
      tun, bpf: fix suspicious RCU usage in tun_{attach, detach}_filter · 5a5abb1f
      Daniel Borkmann authored
      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: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a5abb1f
  2. 31 Mar, 2016 8 commits
  3. 30 Mar, 2016 22 commits
  4. 29 Mar, 2016 1 commit
    • Bjørn Mork's avatar
      qmi_wwan: add "D-Link DWM-221 B1" device id · e84810c7
      Bjørn Mork authored
      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: default avatarThomas Schäfer <tschaefer@t-online.de>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e84810c7