1. 01 Sep, 2016 30 commits
  2. 31 Aug, 2016 10 commits
    • David S. Miller's avatar
      Merge branch 'ppp-recursion' · 127661a4
      David S. Miller authored
      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: default avatarDavid S. Miller <davem@davemloft.net>
      127661a4
    • Guillaume Nault's avatar
      ppp: declare PPP devices as LLTX · 07712770
      Guillaume Nault authored
      
      
      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: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07712770
    • Guillaume Nault's avatar
      ppp: avoid dealock on recursive xmit · 55454a56
      Guillaume Nault authored
      
      
      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: default avatarFeng Gao <gfree.wind@gmail.com>
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      55454a56
    • stephen hemminger's avatar
      xgbe: constify get_netdev_ops and get_ethtool_ops · ce0b15d1
      stephen hemminger authored
      
      
      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: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce0b15d1
    • David S. Miller's avatar
      Merge branch 'dsa-mdb-support' · 07469f8c
      David S. Miller authored
      
      
      Vivien Didelot says:
      
      ====================
      net: dsa: add MDB support
      
      This patchset adds the switchdev MDB object support to the DSA layer.
      
      The MDB support for the mv88e6xxx driver is very similar to the FDB
      support. The FDB operations care about unicast addresses while the MDB
      operations care about multicast addresses.
      
      Both operation set load/purge/dump the Address Translation Table (ATU),
      thus common code is used.
      
      Changes in v2 based on Andrew's comments:
        - drop "group" in multicast database related doc and comment
        - change _one for more relevant _fid in mv88e6xxx_port_db_dump_one
        - return -EOPNOTSUPP if switchdev obj ID is neither _FDB nor _MDB
      ====================
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07469f8c
    • Vivien Didelot's avatar
      net: dsa: mv88e6xxx: add MDB support · 7df8fbdd
      Vivien Didelot authored
      
      
      Add support for the MDB operations. This consists of
      loading/purging/dumping multicast addresses for a given port in the ATU.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7df8fbdd
    • Vivien Didelot's avatar
      net: dsa: mv88e6xxx: make switchdev DB ops generic · 83dabd1f
      Vivien Didelot authored
      
      
      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: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83dabd1f
    • Vivien Didelot's avatar
      net: dsa: add MDB support · 8df30255
      Vivien Didelot authored
      
      
      Add SWITCHDEV_OBJ_ID_PORT_MDB support to the DSA layer.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8df30255
    • David S. Miller's avatar
      Merge branch 'liquidio-CN23XX-part-1' · dbeb714a
      David S. Miller authored
      
      
      Raghu Vatsavayi says:
      
      ====================
      liquidio CN23XX support
      
      Following patchset adds support for new device "CN23XX" in
      liquidio family of adapters. As adviced by you I have split
      the previous V3 patch of 18 patches into two halves. This
      first patchset has first 10 patches, which are tested against
      net-next. I will post the second half after this one.
      
      This V4 patch also addressed all the comments from previous
      submission:
      1) Avoid busy loop while reading registers.
      2) Other minor comments about debug messages and constants.
      
      Please apply patches in following order as some of the
      patches depend on earlier patches.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dbeb714a
    • Raghu Vatsavayi's avatar
      c0eab5b3