1. 01 Feb, 2023 11 commits
  2. 31 Jan, 2023 22 commits
  3. 30 Jan, 2023 7 commits
    • David S. Miller's avatar
      Merge branch 'devlink-next' · 90e8ca0a
      David S. Miller authored
      Jakub Kicinski says:
      
      ====================
      devlink: fix reload notifications and remove features
      
      First two patches adjust notifications during devlink reload.
      The last patch removes no longer needed devlink features.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      90e8ca0a
    • Jiri Pirko's avatar
      devlink: remove devlink features · fb8421a9
      Jiri Pirko authored
      Devlink features were introduced to disallow devlink reload calls of
      userspace before the devlink was fully initialized. The reason for this
      workaround was the fact that devlink reload was originally called
      without devlink instance lock held.
      
      However, with recent changes that converted devlink reload to be
      performed under devlink instance lock, this is redundant so remove
      devlink features entirely.
      
      Note that mlx5 used this to enable devlink reload conditionally only
      when device didn't act as multi port slave. Move the multi port check
      into mlx5_devlink_reload_down() callback alongside with the other
      checks preventing the device from reload in certain states.
      Signed-off-by: default avatarJiri Pirko <jiri@nvidia.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb8421a9
    • Jiri Pirko's avatar
      devlink: send objects notifications during devlink reload · a131315a
      Jiri Pirko authored
      Currently, the notifications are only sent for params. People who
      introduced other objects forgot to add the reload notifications here.
      
      To make sure all notifications happen according to existing comment,
      benefit from existence of devlink_notify_register/unregister() helpers
      and use them in reload code.
      Signed-off-by: default avatarJiri Pirko <jiri@nvidia.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a131315a
    • Jiri Pirko's avatar
      devlink: move devlink reload notifications back in between _down() and _up() calls · 7d7e9169
      Jiri Pirko authored
      This effectively reverts commit 05a7f4a8 ("devlink: Break parameter
      notification sequence to be before/after unload/load driver").
      
      Cited commit resolved a problem in mlx5 params implementation,
      when param notification code accessed memory previously freed
      during reload.
      
      Now, when the params can be registered and unregistered when devlink
      instance is registered, mlx5 code unregisters the problematic param
      during devlink reload. The fix is therefore no longer needed.
      
      Current behavior is a it problematic, as it sends DEL notifications even
      in potential case when reload_down() call fails which might confuse
      userspace notifications listener.
      
      So move the reload notifications back where they were originally in
      between reload_down() and reload_up() calls.
      Signed-off-by: default avatarJiri Pirko <jiri@nvidia.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7d7e9169
    • David S. Miller's avatar
      Merge branch 'sparx5-ES2-VCAP-support' · 166a1a5a
      David S. Miller authored
      Steen Hegelund says:
      
      ====================
      Adding Sparx5 ES2 VCAP support
      
      This provides the Egress Stage 2 (ES2) VCAP (Versatile Content-Aware
      Processor) support for the Sparx5 platform.
      
      The ES2 VCAP is an Egress Access Control VCAP that uses frame keyfields and
      previously classified keyfields to apply e.g. policing, trapping or
      mirroring to frames.
      
      The ES2 VCAP has 2 lookups and they are accessible with a TC chain id:
      
      - chain 20000000: ES2 Lookup 0
      - chain 20100000: ES2 Lookup 1
      
      As the other Sparx5 VCAPs the ES2 VCAP has its own lookup/port keyset
      configuration that decides which keys will be used for matching on which
      traffic type.
      
      The ES2 VCAP has these traffic classifications:
      
      - IPv4 frames
      - IPv6 frames
      - Other frames
      
      The ES2 VCAP can match on an ISDX key (Ingress Service Index) as one of the
      frame metadata keyfields.  The IS0 VCAP can update this key using its
      actions, and this allows a IS0 VCAP rule to be linked to an ES2 rule.
      
      This is similar to how the IS0 VCAP and the IS2 VCAP use the PAG
      (Policy Association Group) keyfield to link rules.
      
      From user space this is exposed via "chain offsets", so an IS0 rule with a
      "goto chain 20000015" action will use an ISDX key value of 15 to link to a
      rule in the ES2 VCAP attached to the same chain id.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      166a1a5a
    • Steen Hegelund's avatar
      net: microchip: sparx5: Add KUNIT tests for enabling/disabling chains · 1f741f00
      Steen Hegelund authored
      This enhances the KUNIT test of the VCAP API with tests of the chaining
      functionality.
      Signed-off-by: default avatarSteen Hegelund <steen.hegelund@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f741f00
    • Steen Hegelund's avatar
      net: microchip: sparx5: Add TC support for the ES2 VCAP · 7b911a53
      Steen Hegelund authored
      This enables the TC command to use the Sparx5 ES2 VCAP, and provides a new
      ES2 ethertype table and handling of rule links between IS0 and ES2.
      Signed-off-by: default avatarSteen Hegelund <steen.hegelund@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7b911a53