1. 25 7月, 2020 3 次提交
  2. 13 7月, 2020 1 次提交
  3. 06 7月, 2020 1 次提交
  4. 11 5月, 2020 1 次提交
    • V
      net: dsa: permit cross-chip bridging between all trees in the system · f66a6a69
      Vladimir Oltean 提交于
      One way of utilizing DSA is by cascading switches which do not all have
      compatible taggers. Consider the following real-life topology:
      
            +---------------------------------------------------------------+
            | LS1028A                                                       |
            |               +------------------------------+                |
            |               |      DSA master for Felix    |                |
            |               |(internal ENETC port 2: eno2))|                |
            |  +------------+------------------------------+-------------+  |
            |  | Felix embedded L2 switch                                |  |
            |  |                                                         |  |
            |  | +--------------+   +--------------+   +--------------+  |  |
            |  | |DSA master for|   |DSA master for|   |DSA master for|  |  |
            |  | |  SJA1105 1   |   |  SJA1105 2   |   |  SJA1105 3   |  |  |
            |  | |(Felix port 1)|   |(Felix port 2)|   |(Felix port 3)|  |  |
            +--+-+--------------+---+--------------+---+--------------+--+--+
      
      +-----------------------+ +-----------------------+ +-----------------------+
      |   SJA1105 switch 1    | |   SJA1105 switch 2    | |   SJA1105 switch 3    |
      +-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
      |sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3|
      +-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
      
      The above can be described in the device tree as follows (obviously not
      complete):
      
      mscc_felix {
      	dsa,member = <0 0>;
      	ports {
      		port@4 {
      			ethernet = <&enetc_port2>;
      		};
      	};
      };
      
      sja1105_switch1 {
      	dsa,member = <1 1>;
      	ports {
      		port@4 {
      			ethernet = <&mscc_felix_port1>;
      		};
      	};
      };
      
      sja1105_switch2 {
      	dsa,member = <2 2>;
      	ports {
      		port@4 {
      			ethernet = <&mscc_felix_port2>;
      		};
      	};
      };
      
      sja1105_switch3 {
      	dsa,member = <3 3>;
      	ports {
      		port@4 {
      			ethernet = <&mscc_felix_port3>;
      		};
      	};
      };
      
      Basically we instantiate one DSA switch tree for every hardware switch
      in the system, but we still give them globally unique switch IDs (will
      come back to that later). Having 3 disjoint switch trees makes the
      tagger drivers "just work", because net devices are registered for the
      3 Felix DSA master ports, and they are also DSA slave ports to the ENETC
      port. So packets received on the ENETC port are stripped of their
      stacked DSA tags one by one.
      
      Currently, hardware bridging between ports on the same sja1105 chip is
      possible, but switching between sja1105 ports on different chips is
      handled by the software bridge. This is fine, but we can do better.
      
      In fact, the dsa_8021q tag used by sja1105 is compatible with cascading.
      In other words, a sja1105 switch can correctly parse and route a packet
      containing a dsa_8021q tag. So if we could enable hardware bridging on
      the Felix DSA master ports, cross-chip bridging could be completely
      offloaded.
      
      Such as system would be used as follows:
      
      ip link add dev br0 type bridge && ip link set dev br0 up
      for port in sw0p0 sw0p1 sw0p2 sw0p3 \
      	    sw1p0 sw1p1 sw1p2 sw1p3 \
      	    sw2p0 sw2p1 sw2p2 sw2p3; do
      	ip link set dev $port master br0
      done
      
      The above makes switching between ports on the same row be performed in
      hardware, and between ports on different rows in software. Now assume
      the Felix switch ports are called swp0, swp1, swp2. By running the
      following extra commands:
      
      ip link add dev br1 type bridge && ip link set dev br1 up
      for port in swp0 swp1 swp2; do
      	ip link set dev $port master br1
      done
      
      the CPU no longer sees packets which traverse sja1105 switch boundaries
      and can be forwarded directly by Felix. The br1 bridge would not be used
      for any sort of traffic termination.
      
      For this to work, we need to give drivers an opportunity to listen for
      bridging events on DSA trees other than their own, and pass that other
      tree index as argument. I have made the assumption, for the moment, that
      the other existing DSA notifiers don't need to be broadcast to other
      trees. That assumption might turn out to be incorrect. But in the
      meantime, introduce a dsa_broadcast function, similar in purpose to
      dsa_port_notify, which is used only by the bridging notifiers.
      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>
      f66a6a69
  5. 30 4月, 2020 1 次提交
    • J
      net: dsa: mv88e6xxx: remove duplicate assignment of struct members · 98123074
      Jason Yan 提交于
      These struct members named 'phylink_validate' was assigned twice:
      
      static const struct mv88e6xxx_ops mv88e6190_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      };
      
      static const struct mv88e6xxx_ops mv88e6190x_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390x_phylink_validate,
      };
      
      static const struct mv88e6xxx_ops mv88e6191_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      };
      
      static const struct mv88e6xxx_ops mv88e6290_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      };
      
      Remove all the first one and leave the second one which are been used in
      fact. Be aware that for 'mv88e6190x_ops' the assignment functions is
      different while the others are all the same. This fixes the following
      coccicheck warning:
      
      drivers/net/dsa/mv88e6xxx/chip.c:3911:48-49: phylink_validate: first
      occurrence line 3965, second occurrence line 3967
      drivers/net/dsa/mv88e6xxx/chip.c:3970:49-50: phylink_validate: first
      occurrence line 4024, second occurrence line 4026
      drivers/net/dsa/mv88e6xxx/chip.c:4029:48-49: phylink_validate: first
      occurrence line 4082, second occurrence line 4085
      drivers/net/dsa/mv88e6xxx/chip.c:4184:48-49: phylink_validate: first
      occurrence line 4238, second occurrence line 4242
      
      Fixes: 4262c38d ("net: dsa: mv88e6xxx: Add SERDES stats counters to all 6390 family members")
      Signed-off-by: NJason Yan <yanaijie@huawei.com>
      Reviewed-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      98123074
  6. 15 4月, 2020 1 次提交
  7. 16 3月, 2020 5 次提交
  8. 12 3月, 2020 1 次提交
  9. 28 2月, 2020 2 次提交
  10. 27 2月, 2020 1 次提交
  11. 17 2月, 2020 3 次提交
  12. 20 1月, 2020 1 次提交
  13. 09 1月, 2020 1 次提交
    • F
      net: dsa: Get information about stacked DSA protocol · 4d776482
      Florian Fainelli 提交于
      It is possible to stack multiple DSA switches in a way that they are not
      part of the tree (disjoint) but the DSA master of a switch is a DSA
      slave of another. When that happens switch drivers may have to know this
      is the case so as to determine whether their tagging protocol has a
      remove chance of working.
      
      This is useful for specific switch drivers such as b53 where devices
      have been known to be stacked in the wild without the Broadcom tag
      protocol supporting that feature. This allows b53 to continue supporting
      those devices by forcing the disabling of Broadcom tags on the outermost
      switches if necessary.
      
      The get_tag_protocol() function is therefore updated to gain an
      additional enum dsa_tag_protocol argument which denotes the current
      tagging protocol used by the DSA master we are attached to, else
      DSA_TAG_PROTO_NONE for the top of the dsa_switch_tree.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d776482
  14. 07 1月, 2020 2 次提交
  15. 28 12月, 2019 1 次提交
  16. 13 11月, 2019 1 次提交
  17. 12 11月, 2019 2 次提交
  18. 06 11月, 2019 2 次提交
  19. 01 11月, 2019 1 次提交
  20. 29 10月, 2019 1 次提交
  21. 23 10月, 2019 5 次提交
  22. 10 9月, 2019 3 次提交