1. 05 9月, 2016 1 次提交
  2. 03 9月, 2016 11 次提交
  3. 02 9月, 2016 10 次提交
  4. 01 9月, 2016 18 次提交
    • 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
    • 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
    • G
      ppp: avoid dealock on recursive xmit · 55454a56
      Guillaume Nault 提交于
      In case of misconfiguration, a virtual PPP channel might send packets
      back to their parent PPP interface. This typically happens in
      misconfigured L2TP setups, where PPP's peer IP address is set with the
      IP of the L2TP peer.
      When that happens the system hangs due to PPP trying to recursively
      lock its xmit path.
      
      [  243.332155] BUG: spinlock recursion on CPU#1, accel-pppd/926
      [  243.333272]  lock: 0xffff880033d90f18, .magic: dead4ead, .owner: accel-pppd/926, .owner_cpu: 1
      [  243.334859] CPU: 1 PID: 926 Comm: accel-pppd Not tainted 4.8.0-rc2 #1
      [  243.336010] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
      [  243.336018]  ffff7fffffffffff ffff8800319a77a0 ffffffff8128de85 ffff880033d90f18
      [  243.336018]  ffff880033ad8000 ffff8800319a77d8 ffffffff810ad7c0 ffffffff0000039e
      [  243.336018]  ffff880033d90f18 ffff880033d90f60 ffff880033d90f18 ffff880033d90f28
      [  243.336018] Call Trace:
      [  243.336018]  [<ffffffff8128de85>] dump_stack+0x4f/0x65
      [  243.336018]  [<ffffffff810ad7c0>] spin_dump+0xe1/0xeb
      [  243.336018]  [<ffffffff810ad7f0>] spin_bug+0x26/0x28
      [  243.336018]  [<ffffffff810ad8b9>] do_raw_spin_lock+0x5c/0x160
      [  243.336018]  [<ffffffff815522aa>] _raw_spin_lock_bh+0x35/0x3c
      [  243.336018]  [<ffffffffa01a88e2>] ? ppp_push+0xa7/0x82d [ppp_generic]
      [  243.336018]  [<ffffffffa01a88e2>] ppp_push+0xa7/0x82d [ppp_generic]
      [  243.336018]  [<ffffffff810adada>] ? do_raw_spin_unlock+0xc2/0xcc
      [  243.336018]  [<ffffffff81084962>] ? preempt_count_sub+0x13/0xc7
      [  243.336018]  [<ffffffff81552438>] ? _raw_spin_unlock_irqrestore+0x34/0x49
      [  243.336018]  [<ffffffffa01ac657>] ppp_xmit_process+0x48/0x877 [ppp_generic]
      [  243.336018]  [<ffffffff81084962>] ? preempt_count_sub+0x13/0xc7
      [  243.336018]  [<ffffffff81408cd3>] ? skb_queue_tail+0x71/0x7c
      [  243.336018]  [<ffffffffa01ad1c5>] ppp_start_xmit+0x21b/0x22a [ppp_generic]
      [  243.336018]  [<ffffffff81426af1>] dev_hard_start_xmit+0x15e/0x32c
      [  243.336018]  [<ffffffff81454ed7>] sch_direct_xmit+0xd6/0x221
      [  243.336018]  [<ffffffff814273a8>] __dev_queue_xmit+0x52a/0x820
      [  243.336018]  [<ffffffff814276a9>] dev_queue_xmit+0xb/0xd
      [  243.336018]  [<ffffffff81430a3c>] neigh_direct_output+0xc/0xe
      [  243.336018]  [<ffffffff8146b5d7>] ip_finish_output2+0x4d2/0x548
      [  243.336018]  [<ffffffff8146a8e6>] ? dst_mtu+0x29/0x2e
      [  243.336018]  [<ffffffff8146d49c>] ip_finish_output+0x152/0x15e
      [  243.336018]  [<ffffffff8146df84>] ? ip_output+0x74/0x96
      [  243.336018]  [<ffffffff8146df9c>] ip_output+0x8c/0x96
      [  243.336018]  [<ffffffff8146d55e>] ip_local_out+0x41/0x4a
      [  243.336018]  [<ffffffff8146dd15>] ip_queue_xmit+0x531/0x5c5
      [  243.336018]  [<ffffffff814a82cd>] ? udp_set_csum+0x207/0x21e
      [  243.336018]  [<ffffffffa01f2f04>] l2tp_xmit_skb+0x582/0x5d7 [l2tp_core]
      [  243.336018]  [<ffffffffa01ea458>] pppol2tp_xmit+0x1eb/0x257 [l2tp_ppp]
      [  243.336018]  [<ffffffffa01acf17>] ppp_channel_push+0x91/0x102 [ppp_generic]
      [  243.336018]  [<ffffffffa01ad2d8>] ppp_write+0x104/0x11c [ppp_generic]
      [  243.336018]  [<ffffffff811a3c1e>] __vfs_write+0x56/0x120
      [  243.336018]  [<ffffffff81239801>] ? fsnotify_perm+0x27/0x95
      [  243.336018]  [<ffffffff8123ab01>] ? security_file_permission+0x4d/0x54
      [  243.336018]  [<ffffffff811a4ca4>] vfs_write+0xbd/0x11b
      [  243.336018]  [<ffffffff811a5a0a>] SyS_write+0x5e/0x96
      [  243.336018]  [<ffffffff81552a1b>] entry_SYSCALL_64_fastpath+0x13/0x94
      
      The main entry points for sending packets over a PPP unit are the
      .write() and .ndo_start_xmit() callbacks (simplified view):
      
      .write(unit fd) or .ndo_start_xmit()
             \
              CALL ppp_xmit_process()
                     \
                      LOCK unit's xmit path (ppp->wlock)
                      |
                      CALL ppp_push()
                             \
                              LOCK channel's xmit path (chan->downl)
                              |
                              CALL lower layer's .start_xmit() callback
                                     \
                                      ... might recursively call .ndo_start_xmit() ...
                                     /
                              RETURN from .start_xmit()
                              |
                              UNLOCK channel's xmit path
                             /
                      RETURN from ppp_push()
                      |
                      UNLOCK unit's xmit path
                     /
              RETURN from ppp_xmit_process()
      
      Packets can also be directly sent on channels (e.g. LCP packets):
      
      .write(channel fd) or ppp_output_wakeup()
             \
              CALL ppp_channel_push()
                     \
                      LOCK channel's xmit path (chan->downl)
                      |
                      CALL lower layer's .start_xmit() callback
                             \
                              ... might call .ndo_start_xmit() ...
                             /
                      RETURN from .start_xmit()
                      |
                      UNLOCK channel's xmit path
                     /
              RETURN from ppp_channel_push()
      
      Key points about the lower layer's .start_xmit() callback:
      
        * It can be called directly by a channel fd .write() or by
          ppp_output_wakeup() or indirectly by a unit fd .write() or by
          .ndo_start_xmit().
      
        * In any case, it's always called with chan->downl held.
      
        * It might route the packet back to its parent unit using
          .ndo_start_xmit() as entry point.
      
      This patch detects and breaks recursion in ppp_xmit_process(). This
      function is a good candidate for the task because it's called early
      enough after .ndo_start_xmit(), it's always part of the recursion
      loop and it's on the path of whatever entry point is used to send
      a packet on a PPP unit.
      
      Recursion detection is done using the per-cpu ppp_xmit_recursion
      variable.
      
      Since ppp_channel_push() too locks the channel's xmit path and calls
      the lower layer's .start_xmit() callback, we need to also increment
      ppp_xmit_recursion there. However there's no need to check for
      recursion, as it's out of the recursion loop.
      Reported-by: NFeng Gao <gfree.wind@gmail.com>
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      55454a56
    • S
      xgbe: constify get_netdev_ops and get_ethtool_ops · ce0b15d1
      stephen hemminger 提交于
      Casting away const is bad practice. Since this is ARM specific driver
      don't have hardware actually test this.
      
      Having getter functions for ops is really unnecessary code bloat, but
      not going to touch that.
      Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce0b15d1
    • V
      net: dsa: mv88e6xxx: add MDB support · 7df8fbdd
      Vivien Didelot 提交于
      Add support for the MDB operations. This consists of
      loading/purging/dumping multicast addresses for a given port in the ATU.
      Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7df8fbdd
    • V
      net: dsa: mv88e6xxx: make switchdev DB ops generic · 83dabd1f
      Vivien Didelot 提交于
      The MDB support for the mv88e6xxx driver will be very similar to the FDB
      support, since it consists of loading/purging/dumping address to/from
      the Address Translation Unit (ATU).
      
      Prepare the support for MDB by making the FDB code accessing the ATU
      generic. The FDB operations now provide access to the unicast addresses
      while the MDB operations will provide access to the multicast addresses.
      Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83dabd1f
    • R
      liquidio: CN23XX firmware download · c0eab5b3
      Raghu Vatsavayi 提交于
      Add firmware download support for cn23xx device.
      Signed-off-by: NDerek Chickles <derek.chickles@caviumnetworks.com>
      Signed-off-by: NSatanand Burla <satananda.burla@caviumnetworks.com>
      Signed-off-by: NFelix Manlunas <felix.manlunas@caviumnetworks.com>
      Signed-off-by: NRaghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c0eab5b3
    • R
      liquidio: MSIX support for CN23XX · 5b07aee1
      Raghu Vatsavayi 提交于
      This patch adds support msix interrupt for cn23xx device.
      Signed-off-by: NDerek Chickles <derek.chickles@caviumnetworks.com>
      Signed-off-by: NSatanand Burla <satananda.burla@caviumnetworks.com>
      Signed-off-by: NFelix Manlunas <felix.manlunas@caviumnetworks.com>
      Signed-off-by: NRaghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b07aee1
    • R
      liquidio: CN23XX queue manipulation · 1b7c55c4
      Raghu Vatsavayi 提交于
      This patch adds support for cn23xx queue manipulation.
      Signed-off-by: NDerek Chickles <derek.chickles@caviumnetworks.com>
      Signed-off-by: NSatanand Burla <satananda.burla@caviumnetworks.com>
      Signed-off-by: NFelix Manlunas <felix.manlunas@caviumnetworks.com>
      Signed-off-by: NRaghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b7c55c4
    • R
      liquidio: CN23XX register setup · 3451b97c
      Raghu Vatsavayi 提交于
      Adds support for initializing cn23xx device registers
      related to mac, input/output and pf global config.
      Signed-off-by: NDerek Chickles <derek.chickles@caviumnetworks.com>
      Signed-off-by: NSatanand Burla <satananda.burla@caviumnetworks.com>
      Signed-off-by: NFelix Manlunas <felix.manlunas@caviumnetworks.com>
      Signed-off-by: NRaghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3451b97c
    • R
      liquidio: CN23XX device init and sriov config · 72c00912
      Raghu Vatsavayi 提交于
      Add support for cn23xx device init and sriov queue config.
      Signed-off-by: NDerek Chickles <derek.chickles@caviumnetworks.com>
      Signed-off-by: NSatanand Burla <satananda.burla@caviumnetworks.com>
      Signed-off-by: NFelix Manlunas <felix.manlunas@caviumnetworks.com>
      Signed-off-by: NRaghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72c00912