Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 09 6月, 2017 30 次提交
  3. 08 6月, 2017 10 次提交
    • D
      Merge branch 'dsa-add-cross-chip-VLAN-support' · 6c8607eb
      由 David S. Miller 提交于 
      Vivien Didelot says:

====================
net: dsa: add cross-chip VLAN support

The current code in DSA does not support cross-chip VLAN. This means
that in a multi-chip environment such as this one (similar to ZII Rev B)

         [CPU].................... (mdio)
    (eth0) |   :       :          :
          _|_____    _______    _______
         [__sw0__]--[__sw1__]--[__sw2__]
          |  |  |    |  |  |    |  |  |
          v  v  v    v  v  v    v  v  v
          p1 p2 p3   p4 p5 p6   p7 p8 p9

adding a VLAN to p9 won't be enough to reach the CPU, until at least one
port of sw0 and sw1 join the VLAN as well and become aware of the VID.

This patchset makes the DSA core program the VLAN on the CPU and DSA
links itself, which brings seamlessly cross-chip VLAN support to DSA.

With this series applied*, the hardware VLAN tables of a 3-switch setup
look like this after adding a VLAN to only one port of the end switch:

    # cat /sys/class/net/br0/bridge/default_pvid
    42
    # cat /sys/kernel/debug/mv88e6xxx/sw{0,1,2}/vtu
    # ip link set up master br0 dev lan6
    # cat /sys/kernel/debug/mv88e6xxx/sw{0,1,2}/vtu
     VID  FID  SID  0  1  2  3  4  5  6
      42    1    0  x  x  x  x  x  =  =
     VID  FID  SID  0  1  2  3  4  5  6
      42    1    0  x  x  x  x  x  =  =
     VID  FID  SID  0  1  2  3  4  5  6  7  8  9
      42    1    0  u  x  x  x  x  x  x  x  x  =

('x' is excluded, 'u' is untagged, '=' is unmodified DSA and CPU ports.)

Completely removing a VLAN entry (which is currently the responsibility
of drivers anyway) is not supported yet since it requires some caching.

(*) the output is shown from this out-of-tree debugfs patch:
https://github.com/vivien/linux/commit/7b61a684b9d6b6a499135a587c7f62a1fddceb8b.patch

Changes in v2:
  - canonical incrementation (port++ instead of ++port)
  - check CPU and DSA ports before purging a VLAN
  - add Reviewed-by tags
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c8607eb
    • V
      net: dsa: mv88e6xxx: do not skip ports on VLAN del · adc3a9ce
      由 Vivien Didelot 提交于 
      The mv88e6xxx driver currently tries to be smart and remove by itself a
VLAN entry from the VTU when the driven switch sees no user ports as
members of the VLAN.

This is bad in a multi-chip switch fabric, since a chip in between
others may have no bridge port members, but still needs to be aware of
the VID in order to correctly pass frames in the data path.

Now that the DSA core explicitly manages DSA and CPU ports, do not skip
them when checking remaining VLAN members.
Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      adc3a9ce
    • V
      net: dsa: mv88e6xxx: exclude all ports in new VLAN · 553a768d
      由 Vivien Didelot 提交于 
      Now that the DSA core adds the CPU and DSA ports itself to the new VLAN
entry, there is no need to include them as members of this VLAN when
initializing a new VTU entry.

As of now, initialize a new VTU entry with all ports excluded.
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      553a768d
    • V
      net: dsa: add CPU and DSA ports as VLAN members · b2f81d30
      由 Vivien Didelot 提交于 
      In a multi-chip switch fabric, it is currently the responsibility of the
driver to add the CPU or DSA (interconnecting chips together) ports as
members of a new VLAN entry. This makes the drivers more complicated.

We want the DSA drivers to be stupid and the DSA core being the one
responsible for caring about the abstracted switch logic and topology.

Make the DSA core program the CPU and DSA ports as part of the VLAN.

This makes all chips of the data path to be aware of VIDs spanning the
the whole fabric and thus, seamlessly add support for cross-chip VLAN.
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b2f81d30
    • V
      net: dsa: check VLAN capability of every switch · 1ca4aa9c
      由 Vivien Didelot 提交于 
      Now that the VLAN object is propagated to every switch chip of the
switch fabric, we can easily ensure that they all support the required
VLAN operations before modifying an entry on a single switch.

To achieve that, remove the condition skipping other target switches,
and add a bitmap of VLAN members, eventually containing the target port,
if we are programming the switch target.

This will allow us to easily add other VLAN members, such as the DSA or
CPU ports (to introduce cross-chip VLAN support) or the other port
members if we want to reduce hardware accesses later.
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ca4aa9c
    • V
      net: dsa: mv88e6xxx: define membership on VLAN add · c91498e1
      由 Vivien Didelot 提交于 
      Define the target port membership of the VLAN entry in
mv88e6xxx_port_vlan_add where ds is scoped.

Allow the DSA core to call later the port_vlan_add operation for CPU or
DSA ports, by using the Unmodified membership for these ports, as in the
current behavior.
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c91498e1
    • D
      Merge tag 'rxrpc-rewrite-20170607-v2' of... · 7eca9cc5
      由 David S. Miller 提交于 
      Merge tag 'rxrpc-rewrite-20170607-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs

David Howells says:

====================
rxrpc: Tx length parameter

Here's a set of patches that allows someone initiating a client call with
AF_RXRPC to indicate upfront the total amount of data that will be
transmitted.  This will allow AF_RXRPC to encrypt directly from source
buffer to packet rather than having to copy into the buffer and only
encrypt when it's full (the encrypted portion of the packet starts with a
length and so we can't encrypt until we know what the length will be).

The three patches are:

 (1) Provide a means of finding out what control message types are actually
     supported.  EINVAL is reported if an unsupported cmsg type is seen, so
     we don't want to set the new cmsg unless we know it will be accepted.

 (2) Consolidate some stuff into a struct to reduce the parameter count on
     the function that parses the cmsg buffer.

 (3) Introduce the RXRPC_TX_LENGTH cmsg.  This can be provided on the first
     sendmsg() that contributes data to a client call request or a service
     call reply.  If provided, the user must provide exactly that amount of
     data or an error will be incurred.

Changes in version 2:

 (*) struct rxrpc_send_params::tx_total_len should be s64 not u64.  Thanks to
     Julia Lawall for reporting this.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7eca9cc5
    • D
      Merge branch 'qrtr-features' · 546692e1
      由 David S. Miller 提交于 
      Bjorn Andersson says:

====================
Missing QRTR features

The QMUX specification covers packet routing as well as service life cycle and
discovery. The current implementation of qrtr supports the prior part, but in
order to fully implement service management on-top a few more parts are needed.

The first patch in the series serves the purpose of reducing duplication in
patch two and three.

The second and third patch adds two qrtr-level notifications required by the
specification, in order to notify local and remote service controllers about
dying clients.

The last patch serves the purpose of notifying local clients about the presence
of a local service register, allowing them to register services as well as
querying for remote registered services.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      546692e1
    • B
      net: qrtr: Inform open sockets about new controller · b24844b1
      由 Bjorn Andersson 提交于 
      As the higher level communication only deals with "services" the
a service directory is required to keep track of local and remote
services. In order for qrtr clients to be informed about when the
service directory implementation is available some event needs to be
passed to them.

Rather than introducing support for broadcasting such a message in-band
to all open local sockets we flag each socket with ENETRESET, as there
are no other expected operations that would benefit from having support
from locally broadcasting messages.

Cc: Courtney Cavin <ccavin@gmail.com>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b24844b1
    • B
      net: qrtr: Broadcast DEL_CLIENT message when endpoint is closed · 1784473b
      由 Bjorn Andersson 提交于 
      Per the QMUXv2 protocol specificiation a DEL_CLIENT message should be
broadcasted when an endpoint is disconnected.

The protocol specification does suggest that the router can keep track
of which nodes the endpoint has been communicating with to not wake up
sleeping remotes unecessarily, but implementation of this suggestion is
left for the future.

Cc: Courtney Cavin <ccavin@gmail.com>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1784473b