1. 02 7月, 2022 1 次提交
  2. 27 6月, 2022 1 次提交
  3. 18 10月, 2021 2 次提交
  4. 13 10月, 2021 3 次提交
    • V
      net: dsa: tag_ocelot_8021q: break circular dependency with ocelot switch lib · 49f885b2
      Vladimir Oltean 提交于
      Michael reported that when using the "ocelot-8021q" tagging protocol,
      the switch driver module must be manually loaded before the tagging
      protocol can be loaded/is available.
      
      This appears to be the same problem described here:
      https://lore.kernel.org/netdev/20210908220834.d7gmtnwrorhharna@skbuf/
      where due to the fact that DSA tagging protocols make use of symbols
      exported by the switch drivers, circular dependencies appear and this
      breaks module autoloading.
      
      The ocelot_8021q driver needs the ocelot_can_inject() and
      ocelot_port_inject_frame() functions from the switch library. Previously
      the wrong approach was taken to solve that dependency: shims were
      provided for the case where the ocelot switch library was compiled out,
      but that turns out to be insufficient, because the dependency when the
      switch lib _is_ compiled is problematic too.
      
      We cannot declare ocelot_can_inject() and ocelot_port_inject_frame() as
      static inline functions, because these access I/O functions like
      __ocelot_write_ix() which is called by ocelot_write_rix(). Making those
      static inline basically means exposing the whole guts of the ocelot
      switch library, not ideal...
      
      We already have one tagging protocol driver which calls into the switch
      driver during xmit but not using any exported symbol: sja1105_defer_xmit.
      We can do the same thing here: create a kthread worker and one work item
      per skb, and let the switch driver itself do the register accesses to
      send the skb, and then consume it.
      
      Fixes: 0a6f17c6 ("net: dsa: tag_ocelot_8021q: add support for PTP timestamping")
      Reported-by: NMichael Walle <michael@walle.cc>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      49f885b2
    • V
      net: dsa: tag_ocelot: break circular dependency with ocelot switch lib driver · deab6b1c
      Vladimir Oltean 提交于
      As explained here:
      https://lore.kernel.org/netdev/20210908220834.d7gmtnwrorhharna@skbuf/
      DSA tagging protocol drivers cannot depend on symbols exported by switch
      drivers, because this creates a circular dependency that breaks module
      autoloading.
      
      The tag_ocelot.c file depends on the ocelot_ptp_rew_op() function
      exported by the common ocelot switch lib. This function looks at
      OCELOT_SKB_CB(skb) and computes how to populate the REW_OP field of the
      DSA tag, for PTP timestamping (the command: one-step/two-step, and the
      TX timestamp identifier).
      
      None of that requires deep insight into the driver, it is quite
      stateless, as it only depends upon the skb->cb. So let's make it a
      static inline function and put it in include/linux/dsa/ocelot.h, a
      file that despite its name is used by the ocelot switch driver for
      populating the injection header too - since commit 40d3f295 ("net:
      mscc: ocelot: use common tag parsing code with DSA").
      
      With that function declared as static inline, its body is expanded
      inside each call site, so the dependency is broken and the DSA tagger
      can be built without the switch library, upon which the felix driver
      depends.
      
      Fixes: 39e5308b ("net: mscc: ocelot: support PTP Sync one-step timestamping")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      deab6b1c
    • V
      net: dsa: sja1105: break dependency between dsa_port_is_sja1105 and switch driver · 4ac0567e
      Vladimir Oltean 提交于
      It's nice to be able to test a tagging protocol with dsa_loop, but not
      at the cost of losing the ability of building the tagging protocol and
      switch driver as modules, because as things stand, there is a circular
      dependency between the two. Tagging protocol drivers cannot depend on
      switch drivers, that is a hard fact.
      
      The reasoning behind the blamed patch was that accessing dp->priv should
      first make sure that the structure behind that pointer is what we really
      think it is.
      
      Currently the "sja1105" and "sja1110" tagging protocols only operate
      with the sja1105 switch driver, just like any other tagging protocol and
      switch combination. The only way to mix and match them is by modifying
      the code, and this applies to dsa_loop as well (by default that uses
      DSA_TAG_PROTO_NONE). So while in principle there is an issue, in
      practice there isn't one.
      
      Until we extend dsa_loop to allow user space configuration, treat the
      problem as a non-issue and just say that DSA ports found by tag_sja1105
      are always sja1105 ports, which is in fact true. But keep the
      dsa_port_is_sja1105 function so that it's easy to patch it during
      testing, and rely on dead code elimination.
      
      Fixes: 994d2cbb ("net: dsa: tag_sja1105: be dsa_loop-safe")
      Link: https://lore.kernel.org/netdev/20210908220834.d7gmtnwrorhharna@skbuf/Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      4ac0567e
  5. 23 9月, 2021 1 次提交
    • V
      net: dsa: sja1105: break dependency between dsa_port_is_sja1105 and switch driver · f5aef424
      Vladimir Oltean 提交于
      It's nice to be able to test a tagging protocol with dsa_loop, but not
      at the cost of losing the ability of building the tagging protocol and
      switch driver as modules, because as things stand, there is a circular
      dependency between the two. Tagging protocol drivers cannot depend on
      switch drivers, that is a hard fact.
      
      The reasoning behind the blamed patch was that accessing dp->priv should
      first make sure that the structure behind that pointer is what we really
      think it is.
      
      Currently the "sja1105" and "sja1110" tagging protocols only operate
      with the sja1105 switch driver, just like any other tagging protocol and
      switch combination. The only way to mix and match them is by modifying
      the code, and this applies to dsa_loop as well (by default that uses
      DSA_TAG_PROTO_NONE). So while in principle there is an issue, in
      practice there isn't one.
      
      Until we extend dsa_loop to allow user space configuration, treat the
      problem as a non-issue and just say that DSA ports found by tag_sja1105
      are always sja1105 ports, which is in fact true. But keep the
      dsa_port_is_sja1105 function so that it's easy to patch it during
      testing, and rely on dead code elimination.
      
      Fixes: 994d2cbb ("net: dsa: tag_sja1105: be dsa_loop-safe")
      Link: https://lore.kernel.org/netdev/20210908220834.d7gmtnwrorhharna@skbuf/Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f5aef424
  6. 18 8月, 2021 1 次提交
    • V
      net: dsa: tag_sja1105: be dsa_loop-safe · 994d2cbb
      Vladimir Oltean 提交于
      Add support for tag_sja1105 running on non-sja1105 DSA ports, by making
      sure that every time we dereference dp->priv, we check the switch's
      dsa_switch_ops (otherwise we access a struct sja1105_port structure that
      is in fact something else).
      
      This adds an unconditional build-time dependency between sja1105 being
      built as module => tag_sja1105 must also be built as module. This was
      there only for PTP before.
      
      Some sane defaults must also take place when not running on sja1105
      hardware. These are:
      
      - sja1105_xmit_tpid: the sja1105 driver uses different VLAN protocols
        depending on VLAN awareness and switch revision (when an encapsulated
        VLAN must be sent). Default to 0x8100.
      
      - sja1105_rcv_meta_state_machine: this aggregates PTP frames with their
        metadata timestamp frames. When running on non-sja1105 hardware, don't
        do that and accept all frames unmodified.
      
      - sja1105_defer_xmit: calls sja1105_port_deferred_xmit in sja1105_main.c
        which writes a management route over SPI. When not running on sja1105
        hardware, bypass the SPI write and send the frame as-is.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      994d2cbb
  7. 05 8月, 2021 1 次提交
    • V
      net: dsa: tag_sja1105: optionally build as module when switch driver is module if PTP is enabled · f8b17a0b
      Vladimir Oltean 提交于
      TX timestamps are sent by SJA1110 as Ethernet packets containing
      metadata, so they are received by the tagging driver but must be
      processed by the switch driver - the one that is stateful since it
      keeps the TX timestamp queue.
      
      This means that there is an sja1110_process_meta_tstamp() symbol
      exported by the switch driver which is called by the tagging driver.
      
      There is a shim definition for that function when the switch driver is
      not compiled, which does nothing, but that shim is not effective when
      the tagging protocol driver is built-in and the switch driver is a
      module, because built-in code cannot call symbols exported by modules.
      
      So add an optional dependency between the tagger and the switch driver,
      if PTP support is enabled in the switch driver. If PTP is not enabled,
      sja1110_process_meta_tstamp() will translate into the shim "do nothing
      with these meta frames" function.
      
      Fixes: 566b18c8 ("net: dsa: sja1105: implement TX timestamping for SJA1110")
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8b17a0b
  8. 20 7月, 2021 1 次提交
    • V
      net: dsa: build tag_8021q.c as part of DSA core · 8b6e638b
      Vladimir Oltean 提交于
      Upcoming patches will add tag_8021q related logic to switch.c and
      port.c, in order to allow it to make use of cross-chip notifiers.
      In addition, a struct dsa_8021q_context *ctx pointer will be added to
      struct dsa_switch.
      
      It seems fairly low-reward to #ifdef the *ctx from struct dsa_switch and
      to provide shim implementations of the entire tag_8021q.c calling
      surface (not even clear what to do about the tag_8021q cross-chip
      notifiers to avoid compiling them). The runtime overhead for switches
      which don't use tag_8021q is fairly small because all helpers will check
      for ds->tag_8021q_ctx being a NULL pointer and stop there.
      
      So let's make it part of dsa_core.o.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b6e638b
  9. 29 4月, 2021 1 次提交
  10. 28 4月, 2021 1 次提交
    • Y
      net: mscc: ocelot: support PTP Sync one-step timestamping · 39e5308b
      Yangbo Lu 提交于
      Although HWTSTAMP_TX_ONESTEP_SYNC existed in ioctl for hardware timestamp
      configuration, the PTP Sync one-step timestamping had never been supported.
      
      This patch is to truely support it.
      
      - ocelot_port_txtstamp_request()
        This function handles tx timestamp request by storing
        ptp_cmd(tx timestamp type) in OCELOT_SKB_CB(skb)->ptp_cmd,
        and additionally for two-step timestamp storing ts_id in
        OCELOT_SKB_CB(clone)->ptp_cmd.
      
      - ocelot_ptp_rew_op()
        During xmit, this function is called to get rew_op (rewriter option) by
        checking skb->cb for tx timestamp request, and configure to transmitting.
      
      Non-onestep-Sync packet with one-step timestamp request falls back to use
      two-step timestamp.
      Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
      Acked-by: NRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      39e5308b
  11. 21 4月, 2021 1 次提交
  12. 23 3月, 2021 1 次提交
    • A
      dsa: simplify Kconfig symbols and dependencies · 227d7206
      Alexander Lobakin 提交于
      1. Remove CONFIG_HAVE_NET_DSA.
      
      CONFIG_HAVE_NET_DSA is a legacy leftover from the times when drivers
      should have selected CONFIG_NET_DSA manually.
      Currently, all drivers has explicit 'depends on NET_DSA', so this is
      no more needed.
      
      2. CONFIG_HAVE_NET_DSA dependencies became CONFIG_NET_DSA's ones.
      
       - dropped !S390 dependency which was introduced to be sure NET_DSA
         can select CONFIG_PHYLIB. DSA migrated to Phylink almost 3 years
         ago and the PHY library itself doesn't depend on !S390 since
         commit 870a2b5e ("phylib: remove !S390 dependeny from Kconfig");
       - INET dependency is kept to be sure we can select NET_SWITCHDEV;
       - NETDEVICES dependency is kept to be sure we can select PHYLINK.
      
      3. DSA drivers menu now depends on NET_DSA.
      
      Instead on 'depends on NET_DSA' on every single driver, the entire
      menu now depends on it. This eliminates a lot of duplicated lines
      from Kconfig with no loss (when CONFIG_NET_DSA=m, drivers also can
      be only m or n).
      This also has a nice side effect that there's no more empty menu on
      configurations without DSA.
      
      4. Kbuild will now descend into 'drivers/net/dsa' only when
         CONFIG_NET_DSA is y or m.
      
      This is safe since no objects inside this folder can be built without
      DSA core, as well as when CONFIG_NET_DSA=m, no objects can be
      built-in.
      Signed-off-by: NAlexander Lobakin <alobakin@pm.me>
      Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      227d7206
  13. 18 3月, 2021 1 次提交
  14. 27 2月, 2021 1 次提交
  15. 23 2月, 2021 1 次提交
  16. 30 1月, 2021 1 次提交
    • V
      net: dsa: add a second tagger for Ocelot switches based on tag_8021q · 7c83a7c5
      Vladimir Oltean 提交于
      There are use cases for which the existing tagger, based on the NPI
      (Node Processor Interface) functionality, is insufficient.
      
      Namely:
      - Frames injected through the NPI port bypass the frame analyzer, so no
        source address learning is performed, no TSN stream classification,
        etc.
      - Flow control is not functional over an NPI port (PAUSE frames are
        encapsulated in the same Extraction Frame Header as all other frames)
      - There can be at most one NPI port configured for an Ocelot switch. But
        in NXP LS1028A and T1040 there are two Ethernet CPU ports. The non-NPI
        port is currently either disabled, or operated as a plain user port
        (albeit an internally-facing one). Having the ability to configure the
        two CPU ports symmetrically could pave the way for e.g. creating a LAG
        between them, to increase bandwidth seamlessly for the system.
      
      So there is a desire to have an alternative to the NPI mode. This change
      keeps the default tagger for the Seville and Felix switches as "ocelot",
      but it can be changed via the following device attribute:
      
      echo ocelot-8021q > /sys/class/<dsa-master>/dsa/tagging
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      7c83a7c5
  17. 16 1月, 2021 1 次提交
  18. 18 11月, 2020 1 次提交
  19. 06 11月, 2020 1 次提交
  20. 09 7月, 2020 1 次提交
    • L
      net: dsa: tag_rtl4_a: Implement Realtek 4 byte A tag · efd7fe68
      Linus Walleij 提交于
      This implements the known parts of the Realtek 4 byte
      tag protocol version 0xA, as found in the RTL8366RB
      DSA switch.
      
      It is designated as protocol version 0xA as a
      different Realtek 4 byte tag format with protocol
      version 0x9 is known to exist in the Realtek RTL8306
      chips.
      
      The tag and switch chip lacks public documentation, so
      the tag format has been reverse-engineered from
      packet dumps. As only ingress traffic has been available
      for analysis an egress tag has not been possible to
      develop (even using educated guesses about bit fields)
      so this is as far as it gets. It is not known if the
      switch even supports egress tagging.
      
      Excessive attempts to figure out the egress tag format
      was made. When nothing else worked, I just tried all bit
      combinations with 0xannp where a is protocol and p is
      port. I looped through all values several times trying
      to get a response from ping, without any positive
      result.
      
      Using just these ingress tags however, the switch
      functionality is vastly improved and the packets find
      their way into the destination port without any
      tricky VLAN configuration. On the D-Link DIR-685 the
      LAN ports now come up and respond to ping without
      any command line configuration so this is a real
      improvement for users.
      
      Egress packets need to be restricted to the proper
      target ports using VLAN, which the RTL8366RB DSA
      switch driver already sets up.
      
      Cc: DENG Qingfang <dqfext@gmail.com>
      Cc: Mauri Sandberg <sandberg@mailfence.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      efd7fe68
  21. 14 6月, 2020 1 次提交
    • M
      treewide: replace '---help---' in Kconfig files with 'help' · a7f7f624
      Masahiro Yamada 提交于
      Since commit 84af7a61 ("checkpatch: kconfig: prefer 'help' over
      '---help---'"), the number of '---help---' has been gradually
      decreasing, but there are still more than 2400 instances.
      
      This commit finishes the conversion. While I touched the lines,
      I also fixed the indentation.
      
      There are a variety of indentation styles found.
      
        a) 4 spaces + '---help---'
        b) 7 spaces + '---help---'
        c) 8 spaces + '---help---'
        d) 1 space + 1 tab + '---help---'
        e) 1 tab + '---help---'    (correct indentation)
        f) 1 tab + 1 space + '---help---'
        g) 1 tab + 2 spaces + '---help---'
      
      In order to convert all of them to 1 tab + 'help', I ran the
      following commend:
      
        $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
      Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      a7f7f624
  22. 24 4月, 2020 1 次提交
    • A
      net: dsa: add GRO support via gro_cells · e131a563
      Alexander Lobakin 提交于
      gro_cells lib is used by different encapsulating netdevices, such as
      geneve, macsec, vxlan etc. to speed up decapsulated traffic processing.
      CPU tag is a sort of "encapsulation", and we can use the same mechs to
      greatly improve overall DSA performance.
      skbs are passed to the GRO layer after removing CPU tags, so we don't
      need any new packet offload types as it was firstly proposed by me in
      the first GRO-over-DSA variant [1].
      
      The size of struct gro_cells is sizeof(void *), so hot struct
      dsa_slave_priv becomes only 4/8 bytes bigger, and all critical fields
      remain in one 32-byte cacheline.
      The other positive side effect is that drivers for network devices
      that can be shipped as CPU ports of DSA-driven switches can now use
      napi_gro_frags() to pass skbs to kernel. Packets built that way are
      completely non-linear and are likely being dropped without GRO.
      
      This was tested on to-be-mainlined-soon Ethernet driver that uses
      napi_gro_frags(), and the overall performance was on par with the
      variant from [1], sometimes even better due to minimal overhead.
      net.core.gro_normal_batch tuning may help to push it to the limit
      on particular setups and platforms.
      
      iperf3 IPoE VLAN NAT TCP forwarding (port1.218 -> port0) setup
      on 1.2 GHz MIPS board:
      
      5.7-rc2 baseline:
      
      [ID]  Interval         Transfer     Bitrate        Retr
      [ 5]  0.00-120.01 sec  9.00 GBytes  644 Mbits/sec  413  sender
      [ 5]  0.00-120.00 sec  8.99 GBytes  644 Mbits/sec       receiver
      
      Iface      RX packets  TX packets
      eth0       7097731     7097702
      port0      426050      6671829
      port1      6671681     425862
      port1.218  6671677     425851
      
      With this patch:
      
      [ID]  Interval         Transfer     Bitrate        Retr
      [ 5]  0.00-120.01 sec  12.2 GBytes  870 Mbits/sec  122  sender
      [ 5]  0.00-120.00 sec  12.2 GBytes  870 Mbits/sec       receiver
      
      Iface      RX packets  TX packets
      eth0       9474792     9474777
      port0      455200      353288
      port1      9019592     455035
      port1.218  353144      455024
      
      v2:
       - Add some performance examples in the commit message;
       - No functional changes.
      
      [1] https://lore.kernel.org/netdev/20191230143028.27313-1-alobakin@dlink.ru/Signed-off-by: NAlexander Lobakin <bloodyreaper@yandex.ru>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e131a563
  23. 21 12月, 2019 1 次提交
  24. 16 11月, 2019 1 次提交
    • V
      net: dsa: ocelot: add tagger for Ocelot/Felix switches · 8dce89aa
      Vladimir Oltean 提交于
      While it is entirely possible that this tagger format is in fact more
      generic than just these 2 switch families, I don't have that knowledge.
      The Seville switch in NXP T1040 has a similar frame format, but there
      are enough differences (e.g. DEST field starts at bit 57 instead of 56)
      that calling this file tag_vitesse.c is a bit of a stretch at the
      moment. The frame format has been listed in a comment so that people who
      add support for further Vitesse switches can rework this tagger while
      keeping compatibility with Felix.
      
      The "ocelot" name was chosen instead of "felix" because even the Ocelot
      switch can act as a DSA device when it is used in NPI mode, and the Felix
      tagger format is almost identical. Currently it is only used for the
      Felix switch embedded in the NXP LS1028A chip.
      
      The ABI for this tagger should be considered "not stable" at the moment.
      The DSA tag is always placed before the Ethernet header and therefore,
      we are using the long prefix for RX tags to avoid putting the DSA master
      port in promiscuous mode. Once there will be an API in DSA for drivers
      to request DSA masters to be in promiscuous mode unconditionally, we
      will switch to the "no prefix" extraction frame header, which will save
      16 padding bytes for each RX frame.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8dce89aa
  25. 13 11月, 2019 1 次提交
    • F
      net: dsa: Prevent usage of NET_DSA_TAG_8021Q as tagging protocol · 129bd7ca
      Florian Fainelli 提交于
      It is possible for a switch driver to use NET_DSA_TAG_8021Q as a valid
      DSA tagging protocol since it registers itself as such, unfortunately
      since there are not xmit or rcv functions provided, the lack of a xmit()
      function will lead to a NPD in dsa_slave_xmit() to start with.
      
      net/dsa/tag_8021q.c is only comprised of a set of helper functions at
      the moment, but is not a fully autonomous or functional tagging "driver"
      (though it could become later on). We do not have any users of
      NET_DSA_TAG_8021Q so now is a good time to make sure there are not
      issues being encountered by making this file strictly a place holder for
      helper functions.
      Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      129bd7ca
  26. 12 9月, 2019 1 次提交
  27. 07 8月, 2019 1 次提交
  28. 14 6月, 2019 1 次提交
  29. 21 5月, 2019 1 次提交
  30. 06 5月, 2019 2 次提交
    • V
      net: dsa: sja1105: Add support for traffic through standalone ports · 227d07a0
      Vladimir Oltean 提交于
      In order to support this, we are creating a make-shift switch tag out of
      a VLAN trunk configured on the CPU port. Termination of normal traffic
      on switch ports only works when not under a vlan_filtering bridge.
      Termination of management (PTP, BPDU) traffic works under all
      circumstances because it uses a different tagging mechanism
      (incl_srcpt). We are making use of the generic CONFIG_NET_DSA_TAG_8021Q
      code and leveraging it from our own CONFIG_NET_DSA_TAG_SJA1105.
      
      There are two types of traffic: regular and link-local.
      
      The link-local traffic received on the CPU port is trapped from the
      switch's regular forwarding decisions because it matched one of the two
      DMAC filters for management traffic.
      
      On transmission, the switch requires special massaging for these
      link-local frames. Due to a weird implementation of the switching IP, by
      default it drops link-local frames that originate on the CPU port.
      It needs to be told where to forward them to, through an SPI command
      ("management route") that is valid for only a single frame.
      So when we're sending link-local traffic, we are using the
      dsa_defer_xmit mechanism.
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      227d07a0
    • 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
  31. 01 5月, 2019 1 次提交
  32. 29 4月, 2019 1 次提交
    • A
      dsa: Allow tag drivers to be built as modules · 0b9f9dfb
      Andrew Lunn 提交于
      Make the CONFIG symbols tristate and add help text.
      
      The broadcom and Microchip KSZ tag drivers support two different
      tagging protocols in one driver. Add a configuration option for the
      drivers, and then options to select the protocol.
      
      Create a submenu for the tagging drivers.
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      
      v2:
      tab/space cleanup
      Help text wording
      NET_DSA_TAG_BRCM_COMMON and NET_DSA_TAG_KZS_COMMON hidden
      
      v3:
      More tabification
      Punctuation
      
      v4:
      trailler->trailer
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b9f9dfb
  33. 25 3月, 2019 1 次提交
  34. 27 2月, 2019 1 次提交
  35. 17 12月, 2018 1 次提交
  36. 13 9月, 2018 1 次提交