1. 03 9月, 2016 2 次提交
  2. 02 9月, 2016 27 次提交
  3. 01 9月, 2016 11 次提交
    • D
      Merge branch 'asix-pm-improvements' · d00a90ca
      David S. Miller 提交于
      Robert Foss says:
      
      ====================
      net/usb: asix driver improvements
      
      This is a resubmission of v3, since the netdev
      mailinlist was not sent the previous submission.
      
      This series improves power management of the asix driver.
      
       - Suspend/resume support is improved to save needed registers.
       - Device disconnection is improved.
       - Fixes AX88772x resume failures
       - Implementes IEEE 802.3 spec section "22.2.4.1.1 Reset" correctly
       - Fixes AX_CMD_WRITE_MEDIUM_MODE being set incorrectly
      
      Changes since v1:
      - Added proper metadata tags to series.
      - Added two more patches to series.
      
      Changes since v2:
      - Added coverletter
      - Tested patches on AX88772A/AX88772B/AX88178/AX88179 hardware
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d00a90ca
    • R
      net: asix: autoneg will set WRITE_MEDIUM reg · 535baf85
      Robert Foss 提交于
      From: Grant Grundler <grundler@chromium.org>
      
      The miii_nway_restart() causes a PHY link change activity and
      ax88772_link_reset will be called. link_reset will set
      AX_CMD_WRITE_MEDIUM_MODE register correctly.
      
      The asix_write_medium_mode in reset() fills in a default value to the register
      which may be different from the negotiation result. So do this first.
      
      Ignore the ret value since it's ignored in XXX_link_reset() functions.
      Signed-off-by: NGrant Grundler <grundler@google.com>
      Signed-off-by: NRobert Foss <robert.foss@collabora.com>
      Tested-by: NRobert Foss <robert.foss@collabora.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      535baf85
    • R
      net: asix: see 802.3 spec for phy reset · a243c2ef
      Robert Foss 提交于
      From: Grant Grundler <grundler@chromium.org>
      
      https://lkml.org/lkml/2014/11/11/947
      
      Ben Hutchings is correct. IEEE 802.3 spec section "22.2.4.1.1 Reset" requires
      up to 500ms delay. Mitigate the "max" delay by polling the phy until BCM_RESET
      bit is clear.
      Signed-off-by: NGrant Grundler <grundler@chromium.org>
      Signed-off-by: NRobert Foss <robert.foss@collabora.com>
      Tested-by: NRobert Foss <robert.foss@collabora.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a243c2ef
    • R
      net: asix: Fix AX88772x resume failures · 4c1442aa
      Robert Foss 提交于
      From: Allan Chou <allan@asix.com.tw>
      
      The change fixes AX88772x resume failure by
      - Restore incorrect AX88772A PHY registers when resetting
      - Need to stop MAC operation when suspending
      - Need to restart MII when restoring PHY
      Signed-off-by: NAllan Chou <allan@asix.com.tw>
      Signed-off-by: NRobert Foss <robert.foss@collabora.com>
      Tested-by: NRobert Foss <robert.foss@collabora.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c1442aa
    • R
      net: asix: Avoid looping when the device is disconnected · 8a46f665
      Robert Foss 提交于
      From: Vincent Palatin <vpalatin@chromium.org>
      
      Check the answers from the USB stack and avoid re-sending multiple times
      the request if the device has disappeared.
      Signed-off-by: NVincent Palatin <vpalatin@chromium.org>
      Signed-off-by: NRobert Foss <robert.foss@collabora.com>
      Tested-by: NRobert Foss <robert.foss@collabora.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a46f665
    • R
      net: asix: Add in_pm parameter · d9fe64e5
      Robert Foss 提交于
      From: Freddy Xin <freddy@asix.com.tw>
      
      In order to R/W registers in suspend/resume functions, in_pm flags are
      added to some functions to determine whether the nopm version of usb
      functions is called.
      
      Save BMCR and ANAR PHY registers in suspend function and restore them
      in resume function.
      
      Reset HW in resume function to ensure the PHY works correctly.
      Signed-off-by: NFreddy Xin <freddy@asix.com.tw>
      Signed-off-by: NRobert Foss <robert.foss@collabora.com>
      Tested-by: NRobert Foss <robert.foss@collabora.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d9fe64e5
    • J
      net: axienet: constify ethtool_ops structures · c7735f1b
      Julia Lawall 提交于
      Check for ethtool_ops structures that are only stored in the ethtool_ops
      field of a net_device structure or passed as the second argument to
      netdev_set_default_ethtool_ops.  These contexts are declared const, so
      ethtool_ops structures that have these properties can be declared as const
      also.
      
      The semantic patch that makes this change is as follows:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @r disable optional_qualifier@
      identifier i;
      position p;
      @@
      static struct ethtool_ops i@p = { ... };
      
      @ok1@
      identifier r.i;
      struct net_device e;
      position p;
      @@
      e.ethtool_ops = &i@p;
      
      @ok2@
      identifier r.i;
      expression e;
      position p;
      @@
      netdev_set_default_ethtool_ops(e, &i@p)
      
      @bad@
      position p != {r.p,ok1.p,ok2.p};
      identifier r.i;
      @@
      i@p
      
      @depends on !bad disable optional_qualifier@
      identifier r.i;
      @@
      static
      +const
       struct ethtool_ops i = { ... };
      // </smpl>
      Suggested-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7735f1b
    • J
      r8152: constify ethtool_ops structures · 407a471d
      Julia Lawall 提交于
      Check for ethtool_ops structures that are only stored in the ethtool_ops
      field of a net_device structure or passed as the second argument to
      netdev_set_default_ethtool_ops.  These contexts are declared const, so
      ethtool_ops structures that have these properties can be declared as const
      also.
      
      The semantic patch that makes this change is as follows:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @r disable optional_qualifier@
      identifier i;
      position p;
      @@
      static struct ethtool_ops i@p = { ... };
      
      @ok1@
      identifier r.i;
      struct net_device e;
      position p;
      @@
      e.ethtool_ops = &i@p;
      
      @ok2@
      identifier r.i;
      expression e;
      position p;
      @@
      netdev_set_default_ethtool_ops(e, &i@p)
      
      @bad@
      position p != {r.p,ok1.p,ok2.p};
      identifier r.i;
      @@
      i@p
      
      @depends on !bad disable optional_qualifier@
      identifier r.i;
      @@
      static
      +const
       struct ethtool_ops i = { ... };
      // </smpl>
      Suggested-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      407a471d
    • J
      net: mediatek: constify ethtool_ops structures · 6a38cb15
      Julia Lawall 提交于
      Check for ethtool_ops structures that are only stored in the ethtool_ops
      field of a net_device structure or passed as the second argument to
      netdev_set_default_ethtool_ops.  These contexts are declared const, so
      ethtool_ops structures that have these properties can be declared as const
      also.
      
      The semantic patch that makes this change is as follows:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @r disable optional_qualifier@
      identifier i;
      position p;
      @@
      static struct ethtool_ops i@p = { ... };
      
      @ok1@
      identifier r.i;
      struct net_device e;
      position p;
      @@
      e.ethtool_ops = &i@p;
      
      @ok2@
      identifier r.i;
      expression e;
      position p;
      @@
      netdev_set_default_ethtool_ops(e, &i@p)
      
      @bad@
      position p != {r.p,ok1.p,ok2.p};
      identifier r.i;
      @@
      i@p
      
      @depends on !bad disable optional_qualifier@
      identifier r.i;
      @@
      static
      +const
       struct ethtool_ops i = { ... };
      // </smpl>
      Suggested-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a38cb15
    • D
      Merge branch 'ppp-recursion' · 127661a4
      David S. Miller 提交于
      Guillaume Nault says:
      
      ====================
      ppp: fix deadlock upon recursive xmit
      
      This series fixes the issue reported by Feng where packets looping
      through a ppp device makes the module deadlock:
      https://marc.info/?l=linux-netdev&m=147134567319038&w=2
      
      The problem can occur on virtual interfaces (e.g. PPP over L2TP, or
      PPPoE on vxlan devices), when a PPP packet is routed back to the PPP
      interface.
      
      PPP's xmit path isn't reentrant, so patch #1 uses a per-cpu variable
      to detect and break recursion. Patch #2 sets the NETIF_F_LLTX flag to
      avoid lock inversion issues between ppp and txqueue locks.
      
      There are multiple entry points to the PPP xmit path. This series has
      been tested with lockdep and should address recursion issues no matter
      how the packet entered the path.
      
      A similar issue in L2TP is not covered by this series:
      l2tp_xmit_skb() also isn't reentrant, and it can be called as part of
      PPP's xmit path (pppol2tp_xmit()), or directly from the L2TP socket
      (l2tp_ppp_sendmsg()). If a packet is sent by l2tp_ppp_sendmsg() and
      routed to the parent PPP interface, then it's going to hit
      l2tp_xmit_skb() again.
      
      Breaking recursion as done in ppp_generic is not enough, because we'd
      still have a lock inversion issue (locking in l2tp_xmit_skb() can
      happen before or after locking in ppp_generic). The best approach would
      be to use the ip_tunnel functions and remove the socket locking in
      l2tp_xmit_skb(). But that'd be something for net-next.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      127661a4
    • G
      ppp: declare PPP devices as LLTX · 07712770
      Guillaume Nault 提交于
      ppp_xmit_process() already locks the xmit path. If HARD_TX_LOCK() tries
      to hold the _xmit_lock we can get lock inversion.
      
      [  973.726130] ======================================================
      [  973.727311] [ INFO: possible circular locking dependency detected ]
      [  973.728546] 4.8.0-rc2 #1 Tainted: G           O
      [  973.728986] -------------------------------------------------------
      [  973.728986] accel-pppd/1806 is trying to acquire lock:
      [  973.728986]  (&qdisc_xmit_lock_key){+.-...}, at: [<ffffffff8146f6fe>] sch_direct_xmit+0x8d/0x221
      [  973.728986]
      [  973.728986] but task is already holding lock:
      [  973.728986]  (l2tp_sock){+.-...}, at: [<ffffffffa0202c4a>] l2tp_xmit_skb+0x1e8/0x5d7 [l2tp_core]
      [  973.728986]
      [  973.728986] which lock already depends on the new lock.
      [  973.728986]
      [  973.728986]
      [  973.728986] the existing dependency chain (in reverse order) is:
      [  973.728986]
      -> #3 (l2tp_sock){+.-...}:
      [  973.728986]        [<ffffffff810b3130>] lock_acquire+0x150/0x217
      [  973.728986]        [<ffffffff815752f4>] _raw_spin_lock+0x2d/0x3c
      [  973.728986]        [<ffffffffa0202c4a>] l2tp_xmit_skb+0x1e8/0x5d7 [l2tp_core]
      [  973.728986]        [<ffffffffa01b2466>] pppol2tp_xmit+0x1f2/0x25e [l2tp_ppp]
      [  973.728986]        [<ffffffffa0184f59>] ppp_channel_push+0xb5/0x14a [ppp_generic]
      [  973.728986]        [<ffffffffa01853ed>] ppp_write+0x104/0x11c [ppp_generic]
      [  973.728986]        [<ffffffff811b2ec6>] __vfs_write+0x56/0x120
      [  973.728986]        [<ffffffff811b3f4c>] vfs_write+0xbd/0x11b
      [  973.728986]        [<ffffffff811b4cb2>] SyS_write+0x5e/0x96
      [  973.728986]        [<ffffffff81575ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
      [  973.728986]
      -> #2 (&(&pch->downl)->rlock){+.-...}:
      [  973.728986]        [<ffffffff810b3130>] lock_acquire+0x150/0x217
      [  973.728986]        [<ffffffff81575334>] _raw_spin_lock_bh+0x31/0x40
      [  973.728986]        [<ffffffffa01808e2>] ppp_push+0xa7/0x82d [ppp_generic]
      [  973.728986]        [<ffffffffa0184675>] __ppp_xmit_process+0x48/0x877 [ppp_generic]
      [  973.728986]        [<ffffffffa018505b>] ppp_xmit_process+0x4b/0xaf [ppp_generic]
      [  973.728986]        [<ffffffffa01853f7>] ppp_write+0x10e/0x11c [ppp_generic]
      [  973.728986]        [<ffffffff811b2ec6>] __vfs_write+0x56/0x120
      [  973.728986]        [<ffffffff811b3f4c>] vfs_write+0xbd/0x11b
      [  973.728986]        [<ffffffff811b4cb2>] SyS_write+0x5e/0x96
      [  973.728986]        [<ffffffff81575ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
      [  973.728986]
      -> #1 (&(&ppp->wlock)->rlock){+.-...}:
      [  973.728986]        [<ffffffff810b3130>] lock_acquire+0x150/0x217
      [  973.728986]        [<ffffffff81575334>] _raw_spin_lock_bh+0x31/0x40
      [  973.728986]        [<ffffffffa0184654>] __ppp_xmit_process+0x27/0x877 [ppp_generic]
      [  973.728986]        [<ffffffffa018505b>] ppp_xmit_process+0x4b/0xaf [ppp_generic]
      [  973.728986]        [<ffffffffa01852da>] ppp_start_xmit+0x21b/0x22a [ppp_generic]
      [  973.728986]        [<ffffffff8143f767>] dev_hard_start_xmit+0x1a9/0x43d
      [  973.728986]        [<ffffffff8146f747>] sch_direct_xmit+0xd6/0x221
      [  973.728986]        [<ffffffff814401e4>] __dev_queue_xmit+0x62a/0x912
      [  973.728986]        [<ffffffff814404d7>] dev_queue_xmit+0xb/0xd
      [  973.728986]        [<ffffffff81449978>] neigh_direct_output+0xc/0xe
      [  973.728986]        [<ffffffff8150e62b>] ip6_finish_output2+0x5a9/0x623
      [  973.728986]        [<ffffffff81512128>] ip6_output+0x15e/0x16a
      [  973.728986]        [<ffffffff8153ef86>] dst_output+0x76/0x7f
      [  973.728986]        [<ffffffff8153f737>] mld_sendpack+0x335/0x404
      [  973.728986]        [<ffffffff81541c61>] mld_send_initial_cr.part.21+0x99/0xa2
      [  973.728986]        [<ffffffff8154441d>] ipv6_mc_dad_complete+0x42/0x71
      [  973.728986]        [<ffffffff8151c4bd>] addrconf_dad_completed+0x1cf/0x2ea
      [  973.728986]        [<ffffffff8151e4fa>] addrconf_dad_work+0x453/0x520
      [  973.728986]        [<ffffffff8107a393>] process_one_work+0x365/0x6f0
      [  973.728986]        [<ffffffff8107aecd>] worker_thread+0x2de/0x421
      [  973.728986]        [<ffffffff810816fb>] kthread+0x121/0x130
      [  973.728986]        [<ffffffff81575dbf>] ret_from_fork+0x1f/0x40
      [  973.728986]
      -> #0 (&qdisc_xmit_lock_key){+.-...}:
      [  973.728986]        [<ffffffff810b28d6>] __lock_acquire+0x1118/0x1483
      [  973.728986]        [<ffffffff810b3130>] lock_acquire+0x150/0x217
      [  973.728986]        [<ffffffff815752f4>] _raw_spin_lock+0x2d/0x3c
      [  973.728986]        [<ffffffff8146f6fe>] sch_direct_xmit+0x8d/0x221
      [  973.728986]        [<ffffffff814401e4>] __dev_queue_xmit+0x62a/0x912
      [  973.728986]        [<ffffffff814404d7>] dev_queue_xmit+0xb/0xd
      [  973.728986]        [<ffffffff81449978>] neigh_direct_output+0xc/0xe
      [  973.728986]        [<ffffffff81487811>] ip_finish_output2+0x5db/0x609
      [  973.728986]        [<ffffffff81489590>] ip_finish_output+0x152/0x15e
      [  973.728986]        [<ffffffff8148a0d4>] ip_output+0x8c/0x96
      [  973.728986]        [<ffffffff81489652>] ip_local_out+0x41/0x4a
      [  973.728986]        [<ffffffff81489e7d>] ip_queue_xmit+0x5a5/0x609
      [  973.728986]        [<ffffffffa0202fe4>] l2tp_xmit_skb+0x582/0x5d7 [l2tp_core]
      [  973.728986]        [<ffffffffa01b2466>] pppol2tp_xmit+0x1f2/0x25e [l2tp_ppp]
      [  973.728986]        [<ffffffffa0184f59>] ppp_channel_push+0xb5/0x14a [ppp_generic]
      [  973.728986]        [<ffffffffa01853ed>] ppp_write+0x104/0x11c [ppp_generic]
      [  973.728986]        [<ffffffff811b2ec6>] __vfs_write+0x56/0x120
      [  973.728986]        [<ffffffff811b3f4c>] vfs_write+0xbd/0x11b
      [  973.728986]        [<ffffffff811b4cb2>] SyS_write+0x5e/0x96
      [  973.728986]        [<ffffffff81575ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
      [  973.728986]
      [  973.728986] other info that might help us debug this:
      [  973.728986]
      [  973.728986] Chain exists of:
        &qdisc_xmit_lock_key --> &(&pch->downl)->rlock --> l2tp_sock
      
      [  973.728986]  Possible unsafe locking scenario:
      [  973.728986]
      [  973.728986]        CPU0                    CPU1
      [  973.728986]        ----                    ----
      [  973.728986]   lock(l2tp_sock);
      [  973.728986]                                lock(&(&pch->downl)->rlock);
      [  973.728986]                                lock(l2tp_sock);
      [  973.728986]   lock(&qdisc_xmit_lock_key);
      [  973.728986]
      [  973.728986]  *** DEADLOCK ***
      [  973.728986]
      [  973.728986] 6 locks held by accel-pppd/1806:
      [  973.728986]  #0:  (&(&pch->downl)->rlock){+.-...}, at: [<ffffffffa0184efa>] ppp_channel_push+0x56/0x14a [ppp_generic]
      [  973.728986]  #1:  (l2tp_sock){+.-...}, at: [<ffffffffa0202c4a>] l2tp_xmit_skb+0x1e8/0x5d7 [l2tp_core]
      [  973.728986]  #2:  (rcu_read_lock){......}, at: [<ffffffff81486981>] rcu_lock_acquire+0x0/0x20
      [  973.728986]  #3:  (rcu_read_lock_bh){......}, at: [<ffffffff81486981>] rcu_lock_acquire+0x0/0x20
      [  973.728986]  #4:  (rcu_read_lock_bh){......}, at: [<ffffffff814340e3>] rcu_lock_acquire+0x0/0x20
      [  973.728986]  #5:  (dev->qdisc_running_key ?: &qdisc_running_key#2){+.....}, at: [<ffffffff8144011e>] __dev_queue_xmit+0x564/0x912
      [  973.728986]
      [  973.728986] stack backtrace:
      [  973.728986] CPU: 2 PID: 1806 Comm: accel-pppd Tainted: G           O    4.8.0-rc2 #1
      [  973.728986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
      [  973.728986]  ffff7fffffffffff ffff88003436f850 ffffffff812a20f4 ffffffff82156e30
      [  973.728986]  ffffffff82156920 ffff88003436f890 ffffffff8115c759 ffff88003344ae00
      [  973.728986]  ffff88003344b5c0 0000000000000002 0000000000000006 ffff88003344b5e8
      [  973.728986] Call Trace:
      [  973.728986]  [<ffffffff812a20f4>] dump_stack+0x67/0x90
      [  973.728986]  [<ffffffff8115c759>] print_circular_bug+0x22e/0x23c
      [  973.728986]  [<ffffffff810b28d6>] __lock_acquire+0x1118/0x1483
      [  973.728986]  [<ffffffff810b3130>] lock_acquire+0x150/0x217
      [  973.728986]  [<ffffffff810b3130>] ? lock_acquire+0x150/0x217
      [  973.728986]  [<ffffffff8146f6fe>] ? sch_direct_xmit+0x8d/0x221
      [  973.728986]  [<ffffffff815752f4>] _raw_spin_lock+0x2d/0x3c
      [  973.728986]  [<ffffffff8146f6fe>] ? sch_direct_xmit+0x8d/0x221
      [  973.728986]  [<ffffffff8146f6fe>] sch_direct_xmit+0x8d/0x221
      [  973.728986]  [<ffffffff814401e4>] __dev_queue_xmit+0x62a/0x912
      [  973.728986]  [<ffffffff814404d7>] dev_queue_xmit+0xb/0xd
      [  973.728986]  [<ffffffff81449978>] neigh_direct_output+0xc/0xe
      [  973.728986]  [<ffffffff81487811>] ip_finish_output2+0x5db/0x609
      [  973.728986]  [<ffffffff81486853>] ? dst_mtu+0x29/0x2e
      [  973.728986]  [<ffffffff81489590>] ip_finish_output+0x152/0x15e
      [  973.728986]  [<ffffffff8148a0bc>] ? ip_output+0x74/0x96
      [  973.728986]  [<ffffffff8148a0d4>] ip_output+0x8c/0x96
      [  973.728986]  [<ffffffff81489652>] ip_local_out+0x41/0x4a
      [  973.728986]  [<ffffffff81489e7d>] ip_queue_xmit+0x5a5/0x609
      [  973.728986]  [<ffffffff814c559e>] ? udp_set_csum+0x207/0x21e
      [  973.728986]  [<ffffffffa0202fe4>] l2tp_xmit_skb+0x582/0x5d7 [l2tp_core]
      [  973.728986]  [<ffffffffa01b2466>] pppol2tp_xmit+0x1f2/0x25e [l2tp_ppp]
      [  973.728986]  [<ffffffffa0184f59>] ppp_channel_push+0xb5/0x14a [ppp_generic]
      [  973.728986]  [<ffffffffa01853ed>] ppp_write+0x104/0x11c [ppp_generic]
      [  973.728986]  [<ffffffff811b2ec6>] __vfs_write+0x56/0x120
      [  973.728986]  [<ffffffff8124c11d>] ? fsnotify_perm+0x27/0x95
      [  973.728986]  [<ffffffff8124d41d>] ? security_file_permission+0x4d/0x54
      [  973.728986]  [<ffffffff811b3f4c>] vfs_write+0xbd/0x11b
      [  973.728986]  [<ffffffff811b4cb2>] SyS_write+0x5e/0x96
      [  973.728986]  [<ffffffff81575ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
      [  973.728986]  [<ffffffff810ae0fa>] ? trace_hardirqs_off_caller+0x121/0x12f
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      07712770