1. 09 Aug, 2021 1 commit
    • Vladimir Oltean's avatar
      net: dsa: still fast-age ports joining a bridge if they can't configure learning · a4ffe09f
      Vladimir Oltean authored
      Commit 39f32101 ("net: dsa: don't fast age standalone ports")
      assumed that all standalone ports disable address learning, but if the
      switch driver implements .port_fast_age but not .port_bridge_flags (like
      ksz9477, ksz8795, lantiq_gswip, lan9303), then that might not actually
      be true.
      
      So whereas before, the bridge temporarily walking us through the
      BLOCKING STP state meant that the standalone ports had a checkpoint to
      flush their baggage and start fresh when they join a bridge, after that
      commit they no longer do.
      
      Restore the old behavior for these drivers by checking if the switch can
      toggle address learning. If it can't, disregard the "do_fast_age"
      argument and unconditionally perform fast ageing on STP state changes.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4ffe09f
  2. 08 Aug, 2021 9 commits
    • David S. Miller's avatar
      Merge branch 'sja1105-fast-ageing' · cfe908c1
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Fast ageing support for SJA1105 DSA driver
      
      While adding support for flushing dynamically learned FDB entries in the
      sja1105 driver, I noticed a few things that could be improved in DSA.
      Most notably, drivers could omit a fast age when address learning is
      turned off, which might mean that ports leaving a bridge and becoming
      standalone could still have FDB entries pointing towards them. Secondly,
      when DSA fast ages a port after the 'learning' flag has been turned off,
      the software bridge still has the dynamically learned 'master' FDB
      entries installed, and those should be deleted too.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cfe908c1
    • Vladimir Oltean's avatar
      net: dsa: sja1105: add FDB fast ageing support · 5126ec72
      Vladimir Oltean authored
      Delete the dynamically learned FDB entries when the STP state changes
      and when address learning is disabled.
      
      On sja1105 there is no shorthand SPI command for this, so we need to
      walk through the entire FDB to delete.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5126ec72
    • Vladimir Oltean's avatar
      net: dsa: sja1105: rely on DSA core tracking of port learning state · 5313a37b
      Vladimir Oltean authored
      Now that DSA keeps track of the port learning state, it becomes
      superfluous to keep an additional variable with this information in the
      sja1105 driver. Remove it.
      
      The DSA core's learning state is present in struct dsa_port *dp.
      To avoid the antipattern where we iterate through a DSA switch's
      ports and then call dsa_to_port to obtain the "dp" reference (which is
      bad because dsa_to_port iterates through the DSA switch tree once
      again), just iterate through the dst->ports and operate on those
      directly.
      
      The sja1105 had an extra use of priv->learn_ena on non-user ports. DSA
      does not touch the learning state of those ports - drivers are free to
      do what they wish on them. Mark that information with a comment in
      struct dsa_port and let sja1105 set dp->learning for cascade ports.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5313a37b
    • Vladimir Oltean's avatar
      net: dsa: flush the dynamic FDB of the software bridge when fast ageing a port · 9264e4ad
      Vladimir Oltean authored
      Currently, when DSA performs fast ageing on a port, 'bridge fdb' shows
      us that the 'self' entries (corresponding to the hardware bridge, as
      printed by dsa_slave_fdb_dump) are deleted, but the 'master' entries
      (corresponding to the software bridge) aren't.
      
      Indeed, searching through the bridge driver, neither the
      brport_attr_learning handler nor the IFLA_BRPORT_LEARNING handler call
      br_fdb_delete_by_port. However, br_stp_disable_port does, which is one
      of the paths which DSA uses to trigger a fast ageing process anyway.
      
      There is, however, one other very promising caller of
      br_fdb_delete_by_port, and that is the bridge driver's handler of the
      SWITCHDEV_FDB_FLUSH_TO_BRIDGE atomic notifier. Currently the s390/qeth
      HiperSockets card driver is the only user of this.
      
      I can't say I understand that driver's architecture or interaction with
      the bridge, but it appears to not be a switchdev driver in the traditional
      sense of the word. Nonetheless, the mechanism it provides is a useful
      way for DSA to express the fact that it performs fast ageing too, in a
      way that does not change the existing behavior for other drivers.
      
      Cc: Alexandra Winter <wintera@linux.ibm.com>
      Cc: Julian Wiedmann <jwi@linux.ibm.com>
      Cc: Roopa Prabhu <roopa@nvidia.com>
      Cc: Nikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9264e4ad
    • Vladimir Oltean's avatar
      net: dsa: don't fast age bridge ports with learning turned off · 4eab90d9
      Vladimir Oltean authored
      On topology changes, stations that were dynamically learned on ports
      that are no longer part of the active topology must be flushed - this is
      described by clause "17.11 Updating learned station location information"
      of IEEE 802.1D-2004.
      
      However, when address learning on the bridge port is turned off in the
      first place, there is nothing to flush, so skip a potentially expensive
      operation.
      
      We can finally do this now since DSA is aware of the learning state of
      its bridged ports.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4eab90d9
    • Vladimir Oltean's avatar
      net: dsa: centralize fast ageing when address learning is turned off · 045c45d1
      Vladimir Oltean authored
      Currently DSA leaves it down to device drivers to fast age the FDB on a
      port when address learning is disabled on it. There are 2 reasons for
      doing that in the first place:
      
      - when address learning is disabled by user space, through
        IFLA_BRPORT_LEARNING or the brport_attr_learning sysfs, what user
        space typically wants to achieve is to operate in a mode with no
        dynamic FDB entry on that port. But if the port is already up, some
        addresses might have been already learned on it, and it seems silly to
        wait for 5 minutes for them to expire until something useful can be
        done.
      
      - when a port leaves a bridge and becomes standalone, DSA turns off
        address learning on it. This also has the nice side effect of flushing
        the dynamically learned bridge FDB entries on it, which is a good idea
        because standalone ports should not have bridge FDB entries on them.
      
      We let drivers manage fast ageing under this condition because if DSA
      were to do it, it would need to track each port's learning state, and
      act upon the transition, which it currently doesn't.
      
      But there are 2 reasons why doing it is better after all:
      
      - drivers might get it wrong and not do it (see b53_port_set_learning)
      
      - we would like to flush the dynamic entries from the software bridge
        too, and letting drivers do that would be another pain point
      
      So track the port learning state and trigger a fast age process
      automatically within DSA.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      045c45d1
    • Jun Miao's avatar
      atm: horizon: Fix spelling mistakes in TX comment · 64ec13ec
      Jun Miao authored
      It's "must not", not "musn't", meaning "shall not".
      Let's fix that.
      Suggested-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarJun Miao <jun.miao@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64ec13ec
    • Leon Romanovsky's avatar
      devlink: Simplify devlink port API calls · 82564f6c
      Leon Romanovsky authored
      Devlink port already has pointer to the devlink instance and all API
      calls that forward these devlink ports to the drivers perform same
      "devlink_port->devlink" assignment before actual call.
      
      This patch removes useless parameter and allows us in the future
      to create specific devlink_port_ops to manage user space access with
      reliable ops assignment.
      Signed-off-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82564f6c
    • Vladimir Oltean's avatar
      net: dsa: don't fast age standalone ports · 39f32101
      Vladimir Oltean authored
      DSA drives the procedure to flush dynamic FDB entries from a port based
      on the change of STP state: whenever we go from a state where address
      learning is enabled (LEARNING, FORWARDING) to a state where it isn't
      (LISTENING, BLOCKING, DISABLED), we need to flush the existing dynamic
      entries.
      
      However, there are cases when this is not needed. Internally, when a
      DSA switch interface is not under a bridge, DSA still keeps it in the
      "FORWARDING" STP state. And when that interface joins a bridge, the
      bridge will meticulously iterate that port through all STP states,
      starting with BLOCKING and ending with FORWARDING. Because there is a
      state transition from the standalone version of FORWARDING into the
      temporary BLOCKING bridge port state, DSA calls the fast age procedure.
      
      Since commit 5e38c158 ("net: dsa: configure better brport flags when
      ports leave the bridge"), DSA asks standalone ports to disable address
      learning. Therefore, there can be no dynamic FDB entries on a standalone
      port. Therefore, it does not make sense to flush dynamic FDB entries on
      one.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      39f32101
  3. 07 Aug, 2021 7 commits
  4. 06 Aug, 2021 22 commits
  5. 05 Aug, 2021 1 commit
    • Jakub Kicinski's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 0ca8d3ca
      Jakub Kicinski authored
      Build failure in drivers/net/wwan/mhi_wwan_mbim.c:
      add missing parameter (0, assuming we don't want buffer pre-alloc).
      
      Conflict in drivers/net/dsa/sja1105/sja1105_main.c between:
        589918df ("net: dsa: sja1105: be stateless with FDB entries on SJA1105P/Q/R/S/SJA1110 too")
        0fac6aa0 ("net: dsa: sja1105: delete the best_effort_vlan_filtering mode")
      
      Follow the instructions from the commit message of the former commit
      - removed the if conditions. When looking at commit 589918df ("net:
      dsa: sja1105: be stateless with FDB entries on SJA1105P/Q/R/S/SJA1110 too")
      note that the mask_iotag fields get removed by the following patch.
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0ca8d3ca