1. 06 5月, 2019 1 次提交
    • V
      net: dsa: Optional VLAN-based port separation for switches without tagging · f9bbe447
      Vladimir Oltean 提交于
      This patch provides generic DSA code for using VLAN (802.1Q) tags for
      the same purpose as a dedicated switch tag for injection/extraction.
      It is based on the discussions and interest that has been so far
      expressed in https://www.spinics.net/lists/netdev/msg556125.html.
      
      Unlike all other DSA-supported tagging protocols, CONFIG_NET_DSA_TAG_8021Q
      does not offer a complete solution for drivers (nor can it). Instead, it
      provides generic code that driver can opt into calling:
      - dsa_8021q_xmit: Inserts a VLAN header with the specified contents.
        Can be called from another tagging protocol's xmit function.
        Currently the LAN9303 driver is inserting headers that are simply
        802.1Q with custom fields, so this is an opportunity for code reuse.
      - dsa_8021q_rcv: Retrieves the TPID and TCI from a VLAN-tagged skb.
        Removing the VLAN header is left as a decision for the caller to make.
      - dsa_port_setup_8021q_tagging: For each user port, installs an Rx VID
        and a Tx VID, for proper untagged traffic identification on ingress
        and steering on egress. Also sets up the VLAN trunk on the upstream
        (CPU or DSA) port. Drivers are intentionally left to call this
        function explicitly, depending on the context and hardware support.
        The expected switch behavior and VLAN semantics should not be violated
        under any conditions. That is, after calling
        dsa_port_setup_8021q_tagging, the hardware should still pass all
        ingress traffic, be it tagged or untagged.
      
      For uniformity with the other tagging protocols, a module for the
      dsa_8021q_netdev_ops structure is registered, but the typical usage is
      to set up another tagging protocol which selects CONFIG_NET_DSA_TAG_8021Q,
      and calls the API from tag_8021q.h. Null function definitions are also
      provided so that a "depends on" is not forced in the Kconfig.
      
      This tagging protocol only works when switch ports are standalone, or
      when they are added to a VLAN-unaware bridge. It will probably remain
      this way for the reasons below.
      
      When added to a bridge that has vlan_filtering 1, the bridge core will
      install its own VLANs and reset the pvids through switchdev. For the
      bridge core, switchdev is a write-only pipe. All VLAN-related state is
      kept in the bridge core and nothing is read from DSA/switchdev or from
      the driver. So the bridge core will break this port separation because
      it will install the vlan_default_pvid into all switchdev ports.
      
      Even if we could teach the bridge driver about switchdev preference of a
      certain vlan_default_pvid (task difficult in itself since the current
      setting is per-bridge but we would need it per-port), there would still
      exist many other challenges.
      
      Firstly, in the DSA rcv callback, a driver would have to perform an
      iterative reverse lookup to find the correct switch port. That is
      because the port is a bridge slave, so its Rx VID (port PVID) is subject
      to user configuration. How would we ensure that the user doesn't reset
      the pvid to a different value (which would make an O(1) translation
      impossible), or to a non-unique value within this DSA switch tree (which
      would make any translation impossible)?
      
      Finally, not all switch ports are equal in DSA, and that makes it
      difficult for the bridge to be completely aware of this anyway.
      The CPU port needs to transmit tagged packets (VLAN trunk) in order for
      the DSA rcv code to be able to decode source information.
      But the bridge code has absolutely no idea which switch port is the CPU
      port, if nothing else then just because there is no netdevice registered
      by DSA for the CPU port.
      Also DSA does not currently allow the user to specify that they want the
      CPU port to do VLAN trunking anyway. VLANs are added to the CPU port
      using the same flags as they were added on the user port.
      
      So the VLANs installed by dsa_port_setup_8021q_tagging per driver
      request should remain private from the bridge's and user's perspective,
      and should not alter the VLAN semantics observed by the user.
      
      In the current implementation a VLAN range ending at 4095 (VLAN_N_VID)
      is reserved for this purpose. Each port receives a unique Rx VLAN and a
      unique Tx VLAN. Separate VLANs are needed for Rx and Tx because they
      serve different purposes: on Rx the switch must process traffic as
      untagged and process it with a port-based VLAN, but with care not to
      hinder bridging. On the other hand, the Tx VLAN is where the
      reachability restrictions are imposed, since by tagging frames in the
      xmit callback we are telling the switch onto which port to steer the
      frame.
      
      Some general guidance on how this support might be employed for
      real-life hardware (some comments made by Florian Fainelli):
      
      - If the hardware supports VLAN tag stacking, it should somehow back
        up its private VLAN settings when the bridge tries to override them.
        Then the driver could re-apply them as outer tags. Dedicating an outer
        tag per bridge device would allow identical inner tag VID numbers to
        co-exist, yet preserve broadcast domain isolation.
      
      - If the switch cannot handle VLAN tag stacking, it should disable this
        port separation when added as slave to a vlan_filtering bridge, in
        that case having reduced functionality.
      
      - Drivers for old switches that don't support the entire VLAN_N_VID
        range will need to rework the current range selection mechanism.
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: NVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9bbe447
  2. 01 5月, 2019 5 次提交
  3. 29 4月, 2019 5 次提交
  4. 02 4月, 2019 1 次提交
  5. 04 3月, 2019 1 次提交
  6. 25 2月, 2019 1 次提交
  7. 22 2月, 2019 1 次提交
  8. 18 1月, 2019 1 次提交
  9. 17 1月, 2019 1 次提交
  10. 17 12月, 2018 1 次提交
  11. 07 12月, 2018 1 次提交
  12. 13 9月, 2018 1 次提交
  13. 19 7月, 2018 1 次提交
  14. 12 5月, 2018 2 次提交
    • F
      net: dsa: Plug in PHYLINK support · aab9c406
      Florian Fainelli 提交于
      Add support for PHYLINK within the DSA subsystem in order to support more
      complex devices such as pluggable (SFP) and non-pluggable (SFF) modules, 10G
      PHYs, and traditional PHYs. Using PHYLINK allows us to drop some amount of
      complexity we had while probing fixed and non-fixed PHYs using Device Tree.
      
      Because PHYLINK separates the Ethernet MAC/port configuration into different
      stages, we let switch drivers implement those, and for now, we maintain
      functionality by calling dsa_slave_adjust_link() during
      phylink_mac_link_{up,down} which provides semantically equivalent steps.
      
      Drivers willing to take advantage of PHYLINK should implement the phylink_mac_*
      operations that DSA wraps.
      
      We cannot quite remove the adjust_link() callback just yet, because a number of
      drivers rely on that for configuring their "CPU" and "DSA" ports, this is done
      dsa_port_setup_phy_of() and dsa_port_fixed_link_register_of() still.
      
      Drivers that utilize fixed links for user-facing ports (e.g: bcm_sf2) will need
      to implement phylink_mac_ops from now on to preserve functionality, since PHYLINK
      *does not* create a phy_device instance for fixed links.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aab9c406
    • F
      net: dsa: Add PHYLINK switch operations · 11d8f3dd
      Florian Fainelli 提交于
      In preparation for adding support for PHYLINK within DSA, define a number of
      operations that we will need and that switch drivers can start implementing.
      Proper integration with PHYLINK will follow in subsequent patches.
      
      We start selecting PHYLINK (which implies PHYLIB) in net/dsa/Kconfig
      such that drivers can be guaranteed that this dependency is properly
      taken care of and can start referencing PHYLINK helper functions without
      requiring stubs or anything.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11d8f3dd
  15. 27 4月, 2018 2 次提交
  16. 05 3月, 2018 1 次提交
  17. 15 2月, 2018 2 次提交
  18. 08 12月, 2017 1 次提交
  19. 06 12月, 2017 1 次提交
    • V
      net: dsa: return per-port upstream port · 07073c79
      Vivien Didelot 提交于
      The current dsa_upstream_port() helper still assumes a unique CPU port
      in the whole switch fabric. This is becoming wrong, as every port in the
      fabric has its dedicated CPU port, thus every port has an upstream port.
      
      Add a port argument to the dsa_upstream_port() helper and fetch its CPU
      port instead of the deprecated unique fabric CPU port. A CPU or unused
      port has no dedicated CPU port, so return itself in this case.
      
      At the same time, change the return value from u8 to unsigned int since
      there is no need to limit the size here.
      Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      07073c79
  20. 03 12月, 2017 3 次提交
  21. 13 11月, 2017 2 次提交
  22. 09 11月, 2017 2 次提交
  23. 05 11月, 2017 2 次提交
  24. 27 10月, 2017 1 次提交