1. 17 Jul, 2023 19 commits
  2. 14 Jul, 2023 21 commits
    • Jesper Dangaard Brouer's avatar
      gve: trivial spell fix Recive to Receive · 68af9000
      Jesper Dangaard Brouer authored
      Spotted this trivial spell mistake while casually reading
      the google GVE driver code.
      Signed-off-by: default avatarJesper Dangaard Brouer <hawk@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68af9000
    • David S. Miller's avatar
      Merge branch 'mlxsw-rif-pvid' · 382d7dcf
      David S. Miller authored
      Petr Machata says:
      
      ====================
      mlxsw: Manage RIF across PVID changes
      
      The mlxsw driver currently makes the assumption that the user applies
      configuration in a bottom-up manner. Thus netdevices need to be added to
      the bridge before IP addresses are configured on that bridge or SVI added
      on top of it. Enslaving a netdevice to another netdevice that already has
      uppers is in fact forbidden by mlxsw for this reason. Despite this safety,
      it is rather easy to get into situations where the offloaded configuration
      is just plain wrong.
      
      As an example, take a front panel port, configure an IP address: it gets a
      RIF. Now enslave the port to the bridge, and the RIF is gone. Remove the
      port from the bridge again, but the RIF never comes back. There is a number
      of similar situations, where changing the configuration there and back
      utterly breaks the offload.
      
      The situation is going to be made better by implementing a range of replays
      and post-hoc offloads.
      
      In this patch set, address the ordering issues related to creation of
      bridge RIFs. Currently, mlxsw has several shortcomings with regards to RIF
      handling due to PVID changes:
      
      - In order to cause RIF for a bridge device to be created, the user is
        expected first to set PVID, then to add an IP address. The reverse
        ordering is disallowed, which is not very user-friendly.
      
      - When such bridge gets a VLAN upper whose VID was the same as the existing
        PVID, and this VLAN netdevice gets an IP address, a RIF is created for
        this netdevice. The new RIF is then assigned to the 802.1Q FID for the
        given VID. This results in a working configuration. However, then, when
        the VLAN netdevice is removed again, the RIF for the bridge itself is
        never reassociated to the PVID.
      
      - PVID cannot be changed once the bridge has uppers. Presumably this is
        because the driver does not manage RIFs properly in face of PVID changes.
        However, as the previous point shows, it is still possible to get into
        invalid configurations.
      
      This patch set addresses these issues and relaxes some of the ordering
      requirements that mlxsw had. The patch set proceeds as follows:
      
      - In patch #1, pass extack to mlxsw_sp_br_ban_rif_pvid_change()
      
      - To relax ordering between setting PVID and adding an IP address to a
        bridge, mlxsw must be able to request that a RIF is created with a given
        VLAN ID, instead of trying to deduce it from the current netdevice
        settings, which do not reflect the user-requested values yet. This is
        done in patches #2 and #3.
      
      - Similarly, mlxsw_sp_inetaddr_bridge_event() will need to make decisions
        based on the user-requested value of PVID, not the current value. Thus in
        patches #4 and #5, add a new argument which carries the requested PVID
        value.
      
      - Finally in patch #6 relax the ban on PVID changes when a bridge has
        uppers. Instead, add the logic necessary for creation of a RIF as a
        result of PVID change.
      
      - Relevant selftests are presented afterwards. In patch #7 a preparatory
        helper is added to lib.sh. Patches #8, #9, #10 and #11 include selftests
        themselves.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      382d7dcf
    • Petr Machata's avatar
      selftests: router_bridge_pvid_vlan_upper: Add a new selftest · 9cbb3da4
      Petr Machata authored
      This tests whether addition and deletion of a VLAN upper that coincides
      with the current PVID setting throws off forwarding.
      
      This selftests is specifically geared towards offloading drivers. In
      particular, mlxsw used to fail this selftest, and an earlier patch in this
      patchset fixes the issue. However, there's nothing HW-specific in the test
      itself (it absolutely is supposed to pass on SW datapath), and therefore it
      is put into the generic forwarding directory.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9cbb3da4
    • Petr Machata's avatar
      selftests: router_bridge_vlan_upper_pvid: Add a new selftest · b0307b77
      Petr Machata authored
      This tests whether changes to PVID that coincide with an existing VLAN
      upper throw off forwarding. This selftests is specifically geared towards
      offloading drivers, but since there's nothing HW-specific in the test
      itself (it absolutely is supposed to pass on SW datapath), it is put into
      the generic forwarding directory.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0307b77
    • Petr Machata's avatar
      selftests: router_bridge_vlan: Add PVID change test · d4172a93
      Petr Machata authored
      Add an alternative path involving VLAN 777 instead of the current 555. Then
      add tests that verify that marking 777 as PVID makes the 555 path not work,
      and the 777 path work.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4172a93
    • Petr Machata's avatar
      selftests: router_bridge: Add tests to remove and add PVID · c7203a29
      Petr Machata authored
      This test relies on PVID being configured on the bridge itself. Thus when
      it is deconfigured, the system should lose the ability to forward traffic.
      Later when it is added again, the ability to forward traffic should be
      regained. Add tests to exercise these configuration changes and verify
      results.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7203a29
    • Petr Machata's avatar
      selftests: forwarding: lib: Add ping6_, ping_test_fails() · 5f44a714
      Petr Machata authored
      Add two helpers to run a ping test that succeeds when the pings themselves
      fail.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f44a714
    • Petr Machata's avatar
      mlxsw: spectrum_switchdev: Manage RIFs on PVID change · a5b52692
      Petr Machata authored
      Currently, mlxsw has several shortcomings with regards to RIF handling due
      to PVID changes:
      
      - In order to cause RIF for a bridge device to be created, the user is
        expected first to set PVID, then to add an IP address. The reverse
        ordering is disallowed, which is not very user-friendly.
      
      - When such bridge gets a VLAN upper whose VID was the same as the existing
        PVID, and this VLAN netdevice gets an IP address, a RIF is created for
        this netdevice. The new RIF is then assigned to the 802.1Q FID for the
        given VID. This results in a working configuration. However, then, when
        the VLAN netdevice is removed again, the RIF for the bridge itself is
        never reassociated to the VLAN.
      
      - PVID cannot be changed once the bridge has uppers. Presumably this is
        because the driver does not manage RIFs properly in face of PVID changes.
        However, as the previous point shows, it is still possible to get into
        invalid configurations.
      
      In this patch, add the logic necessary for creation of a RIF as a result of
      PVID change. Moreover, when a VLAN upper is created whose VID matches lower
      PVID, do not create RIF for this netdevice.
      
      These changes obviate the need for ordering of IP address additions and
      PVID configuration, so stop forbidding addition of an IP address to a
      PVID-less bridge. Instead, bail out quietly. Also stop preventing PVID
      changes when the bridge has uppers.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5b52692
    • Petr Machata's avatar
      mlxsw: spectrum_router: mlxsw_sp_inetaddr_bridge_event: Add an argument · 3430f2cf
      Petr Machata authored
      For purposes of replay, mlxsw_sp_inetaddr_bridge_event() will need to make
      decisions based on the proposed value of PVID. Querying PVID reveals the
      current settings, not the in-flight values that the user requested and that
      the notifiers are acting upon. Add a parameter, lower_pvid, which carries
      the proposed PVID of the lower bridge, or -1 if the lower is not a bridge.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3430f2cf
    • Petr Machata's avatar
      mlxsw: spectrum_router: Adjust mlxsw_sp_inetaddr_vlan_event() coding style · a24a4d29
      Petr Machata authored
      The bridge branch of the dispatch in this function is going to get more
      code and will need curly braces. Per the doctrine, that means the whole
      if-else chain should get them.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a24a4d29
    • Petr Machata's avatar
      mlxsw: spectrum_router: Take VID for VLAN FIDs from RIF params · a0944b24
      Petr Machata authored
      Currently, when an IP address is added to a bridge that has no PVID, the
      operation is rejected. An IP address addition is interpreted as a request
      to create a RIF for the bridge device, but without a PVID there is no VLAN
      for which the RIF should be created. Thus the correct way to create a RIF
      for a bridge as a user is to first add a PVID, and then add the IP address.
      
      Ideally this ordering requirement would not exist. RIF would be created
      either because an IP address is added, or because a PVID is added,
      depending on which comes last.
      
      For that, the switchdev code (which notices the PVID change request) must
      be able to request that a RIF is created with a given VLAN ID, because at
      the time that the PVID notification is distributed, the PVID setting is not
      yet visible for querying.
      
      Therefore when creating a VLAN-based RIF, use mlxsw_sp_rif_params.vid to
      communicate the VID, and do not determine it ad-hoc in the fid_get
      callback.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0944b24
    • Petr Machata's avatar
      mlxsw: spectrum_router: Pass struct mlxsw_sp_rif_params to fid_get · 5ca9f42c
      Petr Machata authored
      The fid_get callback is called to allocate a FID for the newly-created RIF.
      In a following patch, the fid_get implementation for VLANs will be modified
      to take the VLAN ID from the parameters instead of deducing it from the
      netdevice. To that end, propagate the RIF parameters to the fid_get
      callback.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5ca9f42c
    • Petr Machata's avatar
      mlxsw: spectrum_switchdev: Pass extack to mlxsw_sp_br_ban_rif_pvid_change() · 352be882
      Petr Machata authored
      Currently the reason for rejection of PVID manipulation is dumped to
      syslog, and a generic -EBUSY is returned to the userspace. But
      switchdev_handle_port_obj_add(), through which we get to
      mlxsw_sp_port_vlans_add(), handles extack just fine, and we can pass the
      message this way.
      
      This improves visibility into reasons why the request to change PVID
      was rejected. Before the change:
      
       # bridge vlan add dev br vid 2 self pvid untagged
       RTNETLINK answers: Device or resource busy
       (plus a syslog line)
      
      After the change:
      
       # bridge vlan add dev br vid 2 self pvid untagged
       Error: mlxsw_spectrum: Can't change PVID, it's used by router interface.
      
      Note that this particular error message is going away in the following
      patches. However the ability to pass error messages through extack will be
      useful more broadly for communicating in particular reasons why a RIF
      failed to be created.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      352be882
    • David S. Miller's avatar
      Merge branch 'macsec-selftests' · f16276ad
      David S. Miller authored
      Sabrina Dubroca says:
      
      ====================
      net: add MACsec offload selftests
      
      Patch 1 adds MACsec offload to netdevsim (unchanged from v2).
      
      Patch 2 adds a corresponding selftest to the rtnetlink testsuite.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f16276ad
    • Sabrina Dubroca's avatar
      selftests: rtnetlink: add MACsec offload tests · 3b5222e2
      Sabrina Dubroca authored
      Like the IPsec offload test, this requires netdevsim.
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b5222e2
    • Sabrina Dubroca's avatar
      netdevsim: add dummy macsec offload · 02b34d03
      Sabrina Dubroca authored
      When the kernel is compiled with MACsec support, add the
      NETIF_F_HW_MACSEC feature to netdevsim devices and implement
      macsec_ops.
      
      To allow easy testing of failure from the device, support is limited
      to 3 SecY's per netdevsim device, and 1 RXSC per SecY.
      
      v2:
       - nsim_macsec_add_secy, return -ENOSPC if secy_count isn't full but
         we can't find an empty slot (Simon Horman)
       - add sci_to_cpu to make sparse happy (Simon Horman)
       - remove set but not used secy variable (kernel test robot and
         Simon Horman)
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      02b34d03
    • Jiri Pirko's avatar
      devlink: remove reload failed checks in params get/set callbacks · 633d76ad
      Jiri Pirko authored
      The checks in question were introduced by:
      commit 6b4db2e5 ("devlink: Fix use-after-free after a failed reload").
      That fixed an issue of reload with mlxsw driver.
      
      Back then, that was a valid fix, because there was a limitation
      in place that prevented drivers from registering/unregistering params
      when devlink instance was registered.
      
      It was possible to do the fix differently by changing drivers to
      register/unregister params in appropriate places making sure the ops
      operate only on memory which is allocated and initialized. But that,
      as a dependency, would require to remove the limitation mentioned above.
      
      Eventually, this limitation was lifted by:
      commit 1d18bb1a ("devlink: allow registering parameters after the instance")
      
      Also, the alternative fix (which also fixed another issue) was done by:
      commit 74cbc3c0 ("mlxsw: spectrum_acl_tcam: Move devlink param to TCAM code").
      
      Therefore, the checks are no longer relevant. Each driver should make
      sure to have the params registered only when the memory the ops
      are working with is allocated and initialized.
      
      So remove the checks.
      Signed-off-by: default avatarJiri Pirko <jiri@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      633d76ad
    • David S. Miller's avatar
      Merge branch 'mv88e6xxx-phylink_pcs' · a8fbe1ee
      David S. Miller authored
      Russell King says:
      
      ====================
      Convert mv88e6xxx to phylink_pcs
      
      This series (previously posted with further patches on the 26 June as
      RFC) converts mv88e6xxx to phylink_pcs, and thus moves it from being
      a pre-March 2020 legacy driver.
      
      The first four patches lay the ground-work for the conversion by
      adding four new methods to the phylink_pcs operations structure:
      
        pcs_enable() - called when the PCS is going to start to be used
        pcs_disable() - called when the PCS is no longer being used
      
        pcs_pre_config() - called before the MAC configuration method
        pcs_post_config() - called after the MAC configuration method
            Both of these are necessary for some of the mv88e639x
            workarounds.
      
      We also add the ability to inform phylink of a change to the PCS
      state without involving the MAC later, by providing
      phylink_pcs_change() which takes a phylink_pcs structure rather than
      a phylink structure. phylink maintains which instance the PCS is
      conencted to, so internally it can do the right thing when the PCS
      is in-use.
      
      Then we provide some additional mdiobus and mdiodev accessors that
      we will be using in the new PCS drivers.
      
      The changes for mv88e6xxx follow, and the first one needs to be
      explicitly pointed out - we (Andrew and myself) have both decided that
      all possible approaches to maintaining backwards compatibility with DT
      have been exhaused - everyone has some objection to everything that
      has been proposed. So, after many years of trying, we have decided
      that this is just an impossibility, and with this patch, we are now
      intentionally and knowingly breaking any DT that does not specify the
      CPU and DSA port fixed-link parameters. Hence why Andrew has recently
      been submitting DT update patches. It is regrettable that it has come
      to this.
      
      Following this, we start preparing 88e6xxx for phylink_pcs conversion
      by padding the mac_select_pcs() DSA method, and the internal hooks to
      create and tear-down PCS instances. Rather than bloat the already very
      large mv88e6xxx_ops structure, I decided that it would be better that
      the new internal chip specific PCS methods are all grouped within their
      own structure - and this structure can be declared in the PCS drivers
      themselves.
      
      Then we have the actual conversion patches, one for each family of PCS.
      
      Lastly, we clean up the driver after conversion, removing all the now
      redundant code.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8fbe1ee
    • Russell King (Oracle)'s avatar
      net: dsa: mv88e6xxx: cleanup after phylink_pcs conversion · d20acfdd
      Russell King (Oracle) authored
      Now that mv88e6xxx is completely converted to using phylink_pcs
      support, we have no need for the serdes methods. Remove all this
      infrastructure. Also remove the __maybe_unused from
      mv88e6xxx_pcs_select().
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d20acfdd
    • Russell King (Oracle)'s avatar
      net: dsa: mv88e6xxx: convert 88e639x to phylink_pcs · e5b732a2
      Russell King (Oracle) authored
      Convert the 88E6390, 88E6390X, and 88E6393X family of switches to use
      the phylink_pcs infrastructure.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e5b732a2
    • Russell King's avatar
      net: dsa: mv88e6xxx: convert 88e6352 to phylink_pcs · 85764555
      Russell King authored
      Convert the 88E6352 SERDES code to use the phylink_pcs infrastructure.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      85764555