1. 18 5月, 2022 2 次提交
  2. 28 4月, 2022 1 次提交
  3. 26 4月, 2022 1 次提交
  4. 18 3月, 2022 1 次提交
  5. 10 3月, 2022 1 次提交
  6. 27 2月, 2022 2 次提交
    • V
      net: dsa: pass extack to .port_bridge_join driver methods · 06b9cce4
      Vladimir Oltean 提交于
      As FDB isolation cannot be enforced between VLAN-aware bridges in lack
      of hardware assistance like extra FID bits, it seems plausible that many
      DSA switches cannot do it. Therefore, they need to reject configurations
      with multiple VLAN-aware bridges from the two code paths that can
      transition towards that state:
      
      - joining a VLAN-aware bridge
      - toggling VLAN awareness on an existing bridge
      
      The .port_vlan_filtering method already propagates the netlink extack to
      the driver, let's propagate it from .port_bridge_join too, to make sure
      that the driver can use the same function for both.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06b9cce4
    • V
      net: dsa: request drivers to perform FDB isolation · c2693363
      Vladimir Oltean 提交于
      For DSA, to encourage drivers to perform FDB isolation simply means to
      track which bridge does each FDB and MDB entry belong to. It then
      becomes the driver responsibility to use something that makes the FDB
      entry from one bridge not match the FDB lookup of ports from other
      bridges.
      
      The top-level functions where the bridge is determined are:
      - dsa_port_fdb_{add,del}
      - dsa_port_host_fdb_{add,del}
      - dsa_port_mdb_{add,del}
      - dsa_port_host_mdb_{add,del}
      
      aka the pre-crosschip-notifier functions.
      
      Changing the API to pass a reference to a bridge is not superfluous, and
      looking at the passed bridge argument is not the same as having the
      driver look at dsa_to_port(ds, port)->bridge from the ->port_fdb_add()
      method.
      
      DSA installs FDB and MDB entries on shared (CPU and DSA) ports as well,
      and those do not have any dp->bridge information to retrieve, because
      they are not in any bridge - they are merely the pipes that serve the
      user ports that are in one or multiple bridges.
      
      The struct dsa_bridge associated with each FDB/MDB entry is encapsulated
      in a larger "struct dsa_db" database. Although only databases associated
      to bridges are notified for now, this API will be the starting point for
      implementing IFF_UNICAST_FLT in DSA. There, the idea is to install FDB
      entries on the CPU port which belong to the corresponding user port's
      port database. These are supposed to match only when the port is
      standalone.
      
      It is better to introduce the API in its expected final form than to
      introduce it for bridges first, then to have to change drivers which may
      have made one or more assumptions.
      
      Drivers can use the provided bridge.num, but they can also use a
      different numbering scheme that is more convenient.
      
      DSA must perform refcounting on the CPU and DSA ports by also taking
      into account the bridge number. So if two bridges request the same local
      address, DSA must notify the driver twice, once for each bridge.
      
      In fact, if the driver supports FDB isolation, DSA must perform
      refcounting per bridge, but if the driver doesn't, DSA must refcount
      host addresses across all bridges, otherwise it would be telling the
      driver to delete an FDB entry for a bridge and the driver would delete
      it for all bridges. So introduce a bool fdb_isolation in drivers which
      would make all bridge databases passed to the cross-chip notifier have
      the same number (0). This makes dsa_mac_addr_find() -> dsa_db_equal()
      say that all bridge databases are the same database - which is
      essentially the legacy behavior.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2693363
  7. 20 2月, 2022 1 次提交
  8. 28 1月, 2022 1 次提交
  9. 09 12月, 2021 2 次提交
    • V
      net: dsa: add a "tx_fwd_offload" argument to ->port_bridge_join · b079922b
      Vladimir Oltean 提交于
      This is a preparation patch for the removal of the DSA switch methods
      ->port_bridge_tx_fwd_offload() and ->port_bridge_tx_fwd_unoffload().
      The plan is for the switch to report whether it offloads TX forwarding
      directly as a response to the ->port_bridge_join() method.
      
      This change deals with the noisy portion of converting all existing
      function prototypes to take this new boolean pointer argument.
      The bool is placed in the cross-chip notifier structure for bridge join,
      and a reference to it is provided to drivers. In the next change, DSA
      will then actually look at this value instead of calling
      ->port_bridge_tx_fwd_offload().
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      b079922b
    • V
      net: dsa: keep the bridge_dev and bridge_num as part of the same structure · d3eed0e5
      Vladimir Oltean 提交于
      The main desire behind this is to provide coherent bridge information to
      the fast path without locking.
      
      For example, right now we set dp->bridge_dev and dp->bridge_num from
      separate code paths, it is theoretically possible for a packet
      transmission to read these two port properties consecutively and find a
      bridge number which does not correspond with the bridge device.
      
      Another desire is to start passing more complex bridge information to
      dsa_switch_ops functions. For example, with FDB isolation, it is
      expected that drivers will need to be passed the bridge which requested
      an FDB/MDB entry to be offloaded, and along with that bridge_dev, the
      associated bridge_num should be passed too, in case the driver might
      want to implement an isolation scheme based on that number.
      
      We already pass the {bridge_dev, bridge_num} pair to the TX forwarding
      offload switch API, however we'd like to remove that and squash it into
      the basic bridge join/leave API. So that means we need to pass this
      pair to the bridge join/leave API.
      
      During dsa_port_bridge_leave, first we unset dp->bridge_dev, then we
      call the driver's .port_bridge_leave with what used to be our
      dp->bridge_dev, but provided as an argument.
      
      When bridge_dev and bridge_num get folded into a single structure, we
      need to preserve this behavior in dsa_port_bridge_leave: we need a copy
      of what used to be in dp->bridge.
      
      Switch drivers check bridge membership by comparing dp->bridge_dev with
      the provided bridge_dev, but now, if we provide the struct dsa_bridge as
      a pointer, they cannot keep comparing dp->bridge to the provided
      pointer, since this only points to an on-stack copy. To make this
      obvious and prevent driver writers from forgetting and doing stupid
      things, in this new API, the struct dsa_bridge is provided as a full
      structure (not very large, contains an int and a pointer) instead of a
      pointer. An explicit comparison function needs to be used to determine
      bridge membership: dsa_port_offloads_bridge().
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      d3eed0e5
  10. 27 11月, 2021 1 次提交
    • O
      net: dsa: microchip: implement multi-bridge support · b3612ccd
      Oleksij Rempel 提交于
      Current driver version is able to handle only one bridge at time.
      Configuring two bridges on two different ports would end up shorting this
      bridges by HW. To reproduce it:
      
      	ip l a name br0 type bridge
      	ip l a name br1 type bridge
      	ip l s dev br0 up
      	ip l s dev br1 up
      	ip l s lan1 master br0
      	ip l s dev lan1 up
      	ip l s lan2 master br1
      	ip l s dev lan2 up
      
      	Ping on lan1 and get response on lan2, which should not happen.
      
      This happened, because current driver version is storing one global "Port VLAN
      Membership" and applying it to all ports which are members of any
      bridge.
      To solve this issue, we need to handle each port separately.
      
      This patch is dropping the global port member storage and calculating
      membership dynamically depending on STP state and bridge participation.
      
      Note: STP support was broken before this patch and should be fixed
      separately.
      
      Fixes: c2e86691 ("net: dsa: microchip: break KSZ9477 DSA driver into two files")
      Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
      Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
      Link: https://lore.kernel.org/r/20211126123926.2981028-1-o.rempel@pengutronix.deSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      b3612ccd
  11. 10 8月, 2021 2 次提交
  12. 29 4月, 2021 1 次提交
  13. 28 4月, 2021 2 次提交
  14. 12 1月, 2021 2 次提交
    • V
      net: dsa: remove the transactional logic from VLAN objects · 1958d581
      Vladimir Oltean 提交于
      It should be the driver's business to logically separate its VLAN
      offloading into a preparation and a commit phase, and some drivers don't
      need / can't do this.
      
      So remove the transactional shim from DSA and let drivers propagate
      errors directly from the .port_vlan_add callback.
      
      It would appear that the code has worse error handling now than it had
      before. DSA is the only in-kernel user of switchdev that offloads one
      switchdev object to more than one port: for every VLAN object offloaded
      to a user port, that VLAN is also offloaded to the CPU port. So the
      "prepare for user port -> check for errors -> prepare for CPU port ->
      check for errors -> commit for user port -> commit for CPU port"
      sequence appears to make more sense than the one we are using now:
      "offload to user port -> check for errors -> offload to CPU port ->
      check for errors", but it is really a compromise. In the new way, we can
      catch errors from the commit phase that we previously had to ignore.
      But we have our hands tied and cannot do any rollback now: if we add a
      VLAN on the CPU port and it fails, we can't do the rollback by simply
      deleting it from the user port, because the switchdev API is not so nice
      with us: it could have simply been there already, even with the same
      flags. So we don't even attempt to rollback anything on addition error,
      just leave whatever VLANs managed to get offloaded right where they are.
      This should not be a problem at all in practice.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      1958d581
    • V
      net: dsa: remove the transactional logic from MDB entries · a52b2da7
      Vladimir Oltean 提交于
      For many drivers, the .port_mdb_prepare callback was not a good opportunity
      to avoid any error condition, and they would suppress errors found during
      the actual commit phase.
      
      Where a logical separation between the prepare and the commit phase
      existed, the function that used to implement the .port_mdb_prepare
      callback still exists, but now it is called directly from .port_mdb_add,
      which was modified to return an int code.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NJiri Pirko <jiri@nvidia.com>
      Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
      Reviewed-by: Linus Wallei <linus.walleij@linaro.org> # RTL8366
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      a52b2da7
  15. 03 12月, 2020 2 次提交
  16. 11 9月, 2020 1 次提交
  17. 22 7月, 2020 1 次提交
    • H
      net: dsa: microchip: call phy_remove_link_mode during probe · 3506b2f4
      Helmut Grohne 提交于
      When doing "ip link set dev ... up" for a ksz9477 backed link,
      ksz9477_phy_setup is called and it calls phy_remove_link_mode to remove
      1000baseT HDX. During phy_remove_link_mode, phy_advertise_supported is
      called. Doing so reverts any previous change to advertised link modes
      e.g. using a udevd .link file.
      
      phy_remove_link_mode is not meant to be used while opening a link and
      should be called during phy probe when the link is not yet available to
      userspace.
      
      Therefore move the phy_remove_link_mode calls into
      ksz9477_switch_register. It indirectly calls dsa_register_switch, which
      creates the relevant struct phy_devices and we update the link modes
      right after that. At that time dev->features is already initialized by
      ksz9477_switch_detect.
      
      Remove phy_setup from ksz_dev_ops as no users remain.
      
      Link: https://lore.kernel.org/netdev/20200715192722.GD1256692@lunn.ch/
      Fixes: 42fc6a4c ("net: dsa: microchip: prepare PHY for proper advertisement")
      Signed-off-by: NHelmut Grohne <helmut.grohne@intenta.de>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3506b2f4
  18. 05 7月, 2020 2 次提交
  19. 11 3月, 2020 1 次提交
  20. 18 10月, 2019 1 次提交
    • M
      net: dsa: microchip: Add shared regmap mutex · 013572a2
      Marek Vasut 提交于
      The KSZ driver uses one regmap per register width (8/16/32), each with
      it's own lock, but accessing the same set of registers. In theory, it
      is possible to create a race condition between these regmaps, although
      the underlying bus (SPI or I2C) locking should assure nothing bad will
      really happen and the accesses would be correct.
      
      To make the driver do the right thing, add one single shared mutex for
      all the regmaps used by the driver instead. This assures that even if
      some future hardware is on a bus which does not serialize the accesses
      the same way SPI or I2C does, nothing bad will happen.
      
      Note that the status_mutex was unused and only initied, hence it was
      renamed and repurposed as the regmap mutex.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: George McCollister <george.mccollister@gmail.com>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      013572a2
  21. 16 10月, 2019 1 次提交
  22. 28 9月, 2019 1 次提交
    • M
      net: dsa: microchip: Always set regmap stride to 1 · a3aa6e65
      Marek Vasut 提交于
      The regmap stride is set to 1 for regmap describing 8bit registers already.
      However, for 16/32/64bit registers, the stride is 2/4/8 respectively. This
      is not correct, as the switch protocol supports unaligned register reads
      and writes and the KSZ87xx even uses such unaligned register accesses to
      read e.g. MIB counter.
      
      This patch fixes MIB counter access on KSZ87xx.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: George McCollister <george.mccollister@gmail.com>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Fixes: 46558d60 ("net: dsa: microchip: Initial SPI regmap support")
      Fixes: 255b59ad ("net: dsa: microchip: Factor out regmap config generation into common header")
      Reviewed-by: NGeorge McCollister <george.mccollister@gmail.com>
      Tested-by: NGeorge McCollister <george.mccollister@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a3aa6e65
  23. 12 9月, 2019 1 次提交
  24. 01 9月, 2019 1 次提交
  25. 07 8月, 2019 2 次提交
    • M
      net: dsa: ksz: Merge ksz_priv.h into ksz_common.h · 6a7abc61
      Marek Vasut 提交于
      Merge the two headers into one, no functional change.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Vivien Didelot <vivien.didelot@gmail.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a7abc61
    • M
      net: dsa: ksz: Remove dead code and fix warnings · ffc60b55
      Marek Vasut 提交于
      Remove ksz_port_cleanup(), which is unused. Add missing include
      "ksz_common.h", which fixes the following warning when built with
      make ... W=1
      
      drivers/net/dsa/microchip/ksz_common.c:23:6: warning: no previous prototype for ‘...’ [-Wmissing-prototypes]
      
      Note that the order of the headers cannot be swapped, as that would
      trigger missing forward declaration errors, which would indicate the
      way forward is to merge the two headers into one.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Vivien Didelot <vivien.didelot@gmail.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ffc60b55
  26. 31 7月, 2019 1 次提交
  27. 28 6月, 2019 5 次提交