1. 19 Feb, 2024 3 commits
    • Shannon Nelson's avatar
      pds_core: add simple AER handler · d740f4be
      Shannon Nelson authored
      Set up the pci_error_handlers error_detected and resume to be
      useful in handling AER events.
      Reviewed-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarShannon Nelson <shannon.nelson@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d740f4be
    • David S. Miller's avatar
      Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next · 06d53b03
      David S. Miller authored
      -queue
      
      Tony Nguyen says:
      
      ====================
      i40e: Simplify VSI and VEB handling
      
      Ivan Vecera says:
      
      The series simplifies handling of VSIs and VEBs by introducing for-each
      iterating macros, 'find' helper functions. Also removes the VEB
      recursion because the VEBs cannot have sub-VEBs according datasheet and
      fixes the support for floating VEBs.
      
      The series content:
      Patch 1 - Uses existing helper function for find FDIR VSI instead of loop
      Patch 2 - Adds and uses macros to iterate VSI and VEB arrays
      Patch 3 - Adds 2 helper functions to find VSIs and VEBs by their SEID
      Patch 4 - Fixes broken support for floating VEBs
      Patch 5 - Removes VEB recursion and simplifies VEB handling
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06d53b03
    • Jiri Pirko's avatar
      tools: ynl: don't access uninitialized attr_space variable · d0bcc15c
      Jiri Pirko authored
      If message contains unknown attribute and user passes
      "--process-unknown" command line option, _decode() gets called with space
      arg set to None. In that case, attr_space variable is not initialized
      used which leads to following trace:
      
      Traceback (most recent call last):
        File "./tools/net/ynl/cli.py", line 77, in <module>
          main()
        File "./tools/net/ynl/cli.py", line 68, in main
          reply = ynl.dump(args.dump, attrs)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "tools/net/ynl/lib/ynl.py", line 909, in dump
          return self._op(method, vals, [], dump=True)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "tools/net/ynl/lib/ynl.py", line 894, in _op
          rsp_msg = self._decode(decoded.raw_attrs, op.attr_set.name)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "tools/net/ynl/lib/ynl.py", line 639, in _decode
          self._rsp_add(rsp, attr_name, None, self._decode_unknown(attr))
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "tools/net/ynl/lib/ynl.py", line 569, in _decode_unknown
          return self._decode(NlAttrs(attr.raw), None)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "tools/net/ynl/lib/ynl.py", line 630, in _decode
          search_attrs = SpaceAttrs(attr_space, rsp, outer_attrs)
                                    ^^^^^^^^^^
      UnboundLocalError: cannot access local variable 'attr_space' where it is not associated with a value
      
      Fix this by moving search_attrs assignment under the if statement
      above it to make sure attr_space is initialized.
      
      Fixes: bf8b8323 ("tools/net/ynl: Support sub-messages in nested attribute spaces")
      Signed-off-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0bcc15c
  2. 18 Feb, 2024 3 commits
  3. 17 Feb, 2024 6 commits
  4. 16 Feb, 2024 28 commits
    • Ivan Vecera's avatar
      i40e: Remove VEB recursion · f09cbb6c
      Ivan Vecera authored
      The VEB (virtual embedded switch) as a switch element can be
      connected according datasheet though its uplink to:
      - Physical port
      - Port Virtualizer (not used directly by i40e driver but can
        be present in MFP mode where the physical port is shared
        between PFs)
      - No uplink (aka floating VEB)
      
      But VEB uplink cannot be connected to another VEB and any attempt
      to do so results in:
      
      "i40e 0000:02:00.0: couldn't add VEB, err -EIO aq_err I40E_AQ_RC_ENOENT"
      
      that indicates "the uplink SEID does not point to valid element".
      
      Remove this logic from the driver code this way:
      
      1) For debugfs only allow to build floating VEB (uplink_seid == 0)
         or main VEB (uplink_seid == mac_seid)
      2) Do not recurse in i40e_veb_link_event() as no VEB cannot have
         sub-VEBs
      3) Ditto for i40e_veb_rebuild() + simplify the function as we know
         that the VEB for rebuild can be only the main LAN VEB or some
         of the floating VEBs
      4) In i40e_rebuild() there is no need to check veb->uplink_seid
         as the possible ones are 0 and MAC SEID
      5) In i40e_vsi_release() do not take into account VEBs whose
         uplink is another VEB as this is not possible
      6) Remove veb_idx field from i40e_veb as a VEB cannot have
         sub-VEBs
      
      Tested using i40e debugfs interface:
      1) Initial state
      [root@cnb-03 net-next]# CMD="/sys/kernel/debug/i40e/0000:02:00.0/command"
      [root@cnb-03 net-next]# echo dump switch > $CMD
      [root@cnb-03 net-next]# dmesg -c
      [   98.440641] i40e 0000:02:00.0: header: 3 reported 3 total
      [   98.446053] i40e 0000:02:00.0: type=19 seid=392 uplink=160 downlink=16
      [   98.452593] i40e 0000:02:00.0: type=17 seid=160 uplink=2 downlink=0
      [   98.458856] i40e 0000:02:00.0: type=19 seid=390 uplink=160 downlink=16
      
      2) Add floating VEB
      [root@cnb-03 net-next]# echo add relay > $CMD
      [root@cnb-03 net-next]# dmesg -c
      [  122.745630] i40e 0000:02:00.0: added relay 162
      [root@cnb-03 net-next]# echo dump switch > $CMD
      [root@cnb-03 net-next]# dmesg -c
      [  136.650049] i40e 0000:02:00.0: header: 4 reported 4 total
      [  136.655466] i40e 0000:02:00.0: type=19 seid=392 uplink=160 downlink=16
      [  136.661994] i40e 0000:02:00.0: type=17 seid=160 uplink=2 downlink=0
      [  136.668264] i40e 0000:02:00.0: type=19 seid=390 uplink=160 downlink=16
      [  136.674787] i40e 0000:02:00.0: type=17 seid=162 uplink=0 downlink=0
      
      3) Add VMDQ2 VSI to this new VEB
      [root@cnb-03 net-next]# dmesg -c
      [  168.351763] i40e 0000:02:00.0: added VSI 394 to relay 162
      [  168.374652] enp2s0f0np0v0: NIC Link is Up, 40 Gbps Full Duplex, Flow Control: None
      [root@cnb-03 net-next]# echo dump switch > $CMD
      [root@cnb-03 net-next]# dmesg -c
      [  195.683204] i40e 0000:02:00.0: header: 5 reported 5 total
      [  195.688611] i40e 0000:02:00.0: type=19 seid=394 uplink=162 downlink=16
      [  195.695143] i40e 0000:02:00.0: type=17 seid=162 uplink=0 downlink=0
      [  195.701410] i40e 0000:02:00.0: type=19 seid=392 uplink=160 downlink=16
      [  195.707935] i40e 0000:02:00.0: type=17 seid=160 uplink=2 downlink=0
      [  195.714201] i40e 0000:02:00.0: type=19 seid=390 uplink=160 downlink=16
      
      4) Try to delete the VEB
      [root@cnb-03 net-next]# echo del relay 162 > $CMD
      [root@cnb-03 net-next]# dmesg -c
      [  239.260901] i40e 0000:02:00.0: deleting relay 162
      [  239.265621] i40e 0000:02:00.0: can't remove VEB 162 with 1 VSIs left
      
      5) Do PF reset and check switch status after rebuild
      [root@cnb-03 net-next]# echo pfr > $CMD
      [root@cnb-03 net-next]# echo dump switch > $CMD
      [root@cnb-03 net-next]# dmesg -c
      ...
      [  272.333655] i40e 0000:02:00.0: header: 5 reported 5 total
      [  272.339066] i40e 0000:02:00.0: type=19 seid=394 uplink=162 downlink=16
      [  272.345599] i40e 0000:02:00.0: type=17 seid=162 uplink=0 downlink=0
      [  272.351862] i40e 0000:02:00.0: type=19 seid=392 uplink=160 downlink=16
      [  272.358387] i40e 0000:02:00.0: type=17 seid=160 uplink=2 downlink=0
      [  272.364654] i40e 0000:02:00.0: type=19 seid=390 uplink=160 downlink=16
      
      6) Delete VSI and delete VEB
      [  297.199116] i40e 0000:02:00.0: deleting VSI 394
      [  299.807580] i40e 0000:02:00.0: deleting relay 162
      [  309.767905] i40e 0000:02:00.0: header: 3 reported 3 total
      [  309.773318] i40e 0000:02:00.0: type=19 seid=392 uplink=160 downlink=16
      [  309.779845] i40e 0000:02:00.0: type=17 seid=160 uplink=2 downlink=0
      [  309.786111] i40e 0000:02:00.0: type=19 seid=390 uplink=160 downlink=16
      Reviewed-by: default avatarWojciech Drewek <wojciech.drewek@intel.com>
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      f09cbb6c
    • Ivan Vecera's avatar
      i40e: Fix broken support for floating VEBs · 08cdde31
      Ivan Vecera authored
      Although the i40e supports so-called floating VEB (VEB without
      an uplink connection to external network), this support is
      broken. This functionality is currently unused (except debugfs)
      but it will be used by subsequent series for switchdev mode
      slow-path. Fix this by following:
      
      1) Handle correctly floating VEB (VEB with uplink_seid == 0)
         in i40e_reconstitute_veb() and look for owner VSI and
         create it only for non-floating VEBs and also set bridge
         mode only for such VEBs as the floating ones are using
         always VEB mode.
      2) Handle correctly floating VEB in i40e_veb_release() and
         disallow its release when there are some VSIs. This is
         different from regular VEB that have owner VSI that is
         connected to VEB's uplink after VEB deletion by FW.
      3) Fix i40e_add_veb() to handle 'vsi' that is NULL for floating
         VEBs. For floating VEB use 0 for downlink SEID and 'true'
         for 'default_port' parameters as per datasheet.
      4) Fix 'add relay' command in i40e_dbg_command_write() to allow
         to create floating VEB by 'add relay 0 0' or 'add relay'
      
      Tested using debugfs:
      1) Initial state
      [root@host net-next]# echo dump switch > $CMD
      [root@host net-next]# dmesg -c
      [  173.701286] i40e 0000:02:00.0: header: 3 reported 3 total
      [  173.706701] i40e 0000:02:00.0: type=19 seid=392 uplink=160 downlink=16
      [  173.713241] i40e 0000:02:00.0: type=17 seid=160 uplink=2 downlink=0
      [  173.719507] i40e 0000:02:00.0: type=19 seid=390 uplink=160 downlink=16
      
      2) Add floating VEB
      [root@host net-next]# CMD="/sys/kernel/debug/i40e/0000:02:00.0/command"
      [root@host net-next]# echo add relay > $CMD
      [root@host net-next]# dmesg -c
      [  245.551720] i40e 0000:02:00.0: added relay 162
      [root@host net-next]# echo dump switch > $CMD
      [root@host net-next]# dmesg -c
      [  276.984371] i40e 0000:02:00.0: header: 4 reported 4 total
      [  276.989779] i40e 0000:02:00.0: type=19 seid=392 uplink=160 downlink=16
      [  276.996302] i40e 0000:02:00.0: type=17 seid=160 uplink=2 downlink=0
      [  277.002569] i40e 0000:02:00.0: type=19 seid=390 uplink=160 downlink=16
      [  277.009091] i40e 0000:02:00.0: type=17 seid=162 uplink=0 downlink=0
      
      3) Add VMDQ2 VSI to this new VEB
      [root@host net-next]# echo add vsi 162 > $CMD
      [root@host net-next]# dmesg -c
      [  332.314030] i40e 0000:02:00.0: added VSI 394 to relay 162
      [  332.337486] enp2s0f0np0v0: NIC Link is Up, 40 Gbps Full Duplex, Flow Control: None
      [root@host net-next]# echo dump switch > $CMD
      [root@host net-next]# dmesg -c
      [  387.284490] i40e 0000:02:00.0: header: 5 reported 5 total
      [  387.289904] i40e 0000:02:00.0: type=19 seid=394 uplink=162 downlink=16
      [  387.296446] i40e 0000:02:00.0: type=17 seid=162 uplink=0 downlink=0
      [  387.302708] i40e 0000:02:00.0: type=19 seid=392 uplink=160 downlink=16
      [  387.309234] i40e 0000:02:00.0: type=17 seid=160 uplink=2 downlink=0
      [  387.315500] i40e 0000:02:00.0: type=19 seid=390 uplink=160 downlink=16
      
      4) Try to delete the VEB
      [root@host net-next]# echo del relay 162 > $CMD
      [root@host net-next]# dmesg -c
      [  428.749297] i40e 0000:02:00.0: deleting relay 162
      [  428.754011] i40e 0000:02:00.0: can't remove VEB 162 with 1 VSIs left
      
      5) Do PF reset and check switch status after rebuild
      [root@host net-next]# echo pfr > $CMD
      [root@host net-next]# echo dump switch > $CMD
      [root@host net-next]# dmesg -c
      [  738.056172] i40e 0000:02:00.0: header: 5 reported 5 total
      [  738.061577] i40e 0000:02:00.0: type=19 seid=394 uplink=162 downlink=16
      [  738.068104] i40e 0000:02:00.0: type=17 seid=162 uplink=0 downlink=0
      [  738.074367] i40e 0000:02:00.0: type=19 seid=392 uplink=160 downlink=16
      [  738.080892] i40e 0000:02:00.0: type=17 seid=160 uplink=2 downlink=0
      [  738.087160] i40e 0000:02:00.0: type=19 seid=390 uplink=160 downlink=16
      
      6) Delete VSI and delete VEB
      [root@host net-next]# echo del vsi 394 > $CMD
      [root@host net-next]# echo del relay 162 > $CMD
      [root@host net-next]# echo dump switch > $CMD
      [root@host net-next]# dmesg -c
      [ 1233.081126] i40e 0000:02:00.0: deleting VSI 394
      [ 1239.345139] i40e 0000:02:00.0: deleting relay 162
      [ 1244.886920] i40e 0000:02:00.0: header: 3 reported 3 total
      [ 1244.892328] i40e 0000:02:00.0: type=19 seid=392 uplink=160 downlink=16
      [ 1244.898853] i40e 0000:02:00.0: type=17 seid=160 uplink=2 downlink=0
      [ 1244.905119] i40e 0000:02:00.0: type=19 seid=390 uplink=160 downlink=16
      Reviewed-by: default avatarWojciech Drewek <wojciech.drewek@intel.com>
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      08cdde31
    • Ivan Vecera's avatar
      i40e: Add helpers to find VSI and VEB by SEID and use them · b7fac08d
      Ivan Vecera authored
      Add two helpers i40e_(veb|vsi)_get_by_seid() to find corresponding
      VEB or VSI by their SEID value and use these helpers to replace
      existing open-coded loops.
      Reviewed-by: default avatarWojciech Drewek <wojciech.drewek@intel.com>
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      b7fac08d
    • Ivan Vecera's avatar
      i40e: Introduce and use macros for iterating VSIs and VEBs · b1f1b46f
      Ivan Vecera authored
      Introduce i40e_for_each_vsi() and i40e_for_each_veb() helper
      macros and use them to iterate relevant arrays.
      
      Replace pattern:
      for (i = 0; i < pf->num_alloc_vsi; i++)
      by:
      i40e_for_each_vsi(pf, i, vsi)
      
      and pattern:
      for (i = 0; i < I40E_MAX_VEB; i++)
      by
      i40e_for_each_veb(pf, i, veb)
      
      These macros also check if array item pf->vsi[i] or pf->veb[i]
      are not NULL and skip such items so we can remove redundant
      checks from loop bodies.
      Reviewed-by: default avatarWojciech Drewek <wojciech.drewek@intel.com>
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      b1f1b46f
    • Ivan Vecera's avatar
      i40e: Use existing helper to find flow director VSI · 7e6cec7d
      Ivan Vecera authored
      Use existing i40e_find_vsi_by_type() to find a VSI
      associated with flow director.
      Reviewed-by: default avatarWojciech Drewek <wojciech.drewek@intel.com>
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      7e6cec7d
    • Christian Marangi's avatar
      net: phy: aquantia: add AQR113 PHY ID · 71b605d3
      Christian Marangi authored
      Add Aquantia AQR113 PHY ID. Aquantia AQR113 is just a chip size variant of
      the already supported AQR133C where the only difference is the PHY ID
      and the hw chip size.
      Signed-off-by: default avatarChristian Marangi <ansuelsmth@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71b605d3
    • Diogo Ivo's avatar
      net: ti: icssg-prueth: Remove duplicate cleanup calls in emac_ndo_stop() · 1d085e9c
      Diogo Ivo authored
      Remove the duplicate calls to prueth_emac_stop() and
      prueth_cleanup_tx_chns() in emac_ndo_stop().
      Signed-off-by: default avatarDiogo Ivo <diogo.ivo@siemens.com>
      Reviewed-by: default avatarRoger Quadros <rogerq@kernel.org>
      Reviewed-by: default avatarMD Danish Anwar <danishanwar@ti.com>
      Reviewed-by: default avatarDan Carpenter <dan.carpenter@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d085e9c
    • Geert Uytterhoeven's avatar
      tcp: Spelling s/curcuit/circuit/ · 21bd52ea
      Geert Uytterhoeven authored
      Fix a misspelling of "circuit".
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21bd52ea
    • David S. Miller's avatar
      Merge branch 'ionic-xdp-support' · d70a2a45
      David S. Miller authored
      Shannon Nelson says:
      
      ====================
      ionic: add XDP support
      
      This patchset is new support in ionic for XDP processing,
      including basic XDP on Rx packets, TX and REDIRECT, and frags
      for jumbo frames.
      
      Since ionic has not yet been converted to use the page_pool APIs,
      this uses the simple MEM_TYPE_PAGE_ORDER0 buffering.  There are plans
      to convert the driver in the near future.
      
      v4:
       - removed "inline" from short utility functions
       - changed to use "goto err_out" in ionic_xdp_register_rxq_info()
       - added "continue" to reduce nesting in ionic_xdp_queues_config()
       - used xdp_prog in ionic_rx_clean() to flag whether or not to sync
         the rx buffer after calling ionix_xdp_run()
       - swapped order of XDP_TX and XDP_REDIRECT cases in ionic_xdp_run()
         to make patch 6 a little cleaner
      
      v3:
      https://lore.kernel.org/netdev/20240210004827.53814-1-shannon.nelson@amd.com/
       - removed budget==0 patch, sent it separately to net
      
      v2:
      https://lore.kernel.org/netdev/20240208005725.65134-1-shannon.nelson@amd.com/
       - added calls to txq_trans_cond_update()
       - added a new patch to catch NAPI budget==0
      
      v1:
      https://lore.kernel.org/netdev/20240130013042.11586-1-shannon.nelson@amd.com/
      
      RFC:
      https://lore.kernel.org/netdev/20240118192500.58665-1-shannon.nelson@amd.com/
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d70a2a45
    • Shannon Nelson's avatar
      ionic: implement xdp frags support · 5377805d
      Shannon Nelson authored
      Add support for using scatter-gather / frags in XDP in both
      Rx and Tx paths.
      Co-developed-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarShannon Nelson <shannon.nelson@amd.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5377805d
    • Shannon Nelson's avatar
      ionic: add ndo_xdp_xmit · 26f5726a
      Shannon Nelson authored
      When our ndo_xdp_xmit is called we mark the buffer with
      XDP_REDIRECT so we know to return it to the XDP stack for
      cleaning.
      Co-developed-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarShannon Nelson <shannon.nelson@amd.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26f5726a
    • Shannon Nelson's avatar
      ionic: Add XDP_REDIRECT support · 587fc3f0
      Shannon Nelson authored
      The XDP_REDIRECT packets are given to the XDP stack and
      we drop the use of the related page: it will get freed
      by the driver that ends up doing the Tx.  Because we have
      some hardware configurations with limited queue resources,
      we use the existing datapath Tx queues rather than creating
      and managing a separate set of xdp_tx queues.
      Co-developed-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarShannon Nelson <shannon.nelson@amd.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      587fc3f0
    • Shannon Nelson's avatar
      ionic: Add XDP_TX support · 8eeed837
      Shannon Nelson authored
      The XDP_TX packets get fed back into the Rx queue's partnered
      Tx queue as an xdp_frame.
      Co-developed-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarShannon Nelson <shannon.nelson@amd.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8eeed837
    • Shannon Nelson's avatar
      ionic: Add XDP packet headroom · f81da39b
      Shannon Nelson authored
      If an xdp program is loaded, add headroom at the beginning
      of the frame to allow for editing and insertions that an XDP
      program might need room for, and tailroom used later for XDP
      frame tracking.  These are only needed in the first Rx buffer
      in a packet, not for any trailing frags.
      Co-developed-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarShannon Nelson <shannon.nelson@amd.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f81da39b
    • Shannon Nelson's avatar
      ionic: add initial framework for XDP support · 180e35cd
      Shannon Nelson authored
      Set up the basics for running Rx packets through XDP programs.
      Add new queue setup and teardown steps for adding/removing an
      XDP program, and add the call to run the XDP on a packet.
      
      The XDP frame size needs to be the MTU plus standard ethernet
      header, plus head room for XDP scribblings and tail room for a
      struct skb_shared_info.  Also, at this point, we don't support
      XDP frags, only a single contiguous Rx buffer.  This means
      that our page splitting is not very useful, so when XDP is in
      use we need to use the full Rx buffer size and not do sharing.
      Co-developed-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Signed-off-by: default avatarShannon Nelson <shannon.nelson@amd.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      180e35cd
    • Shannon Nelson's avatar
      ionic: use dma range APIs · d67ee210
      Shannon Nelson authored
      Convert Rx datapath handling to use the DMA range APIs
      in preparation for adding XDP handling.
      Signed-off-by: default avatarShannon Nelson <shannon.nelson@amd.com>
      Reviewed-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d67ee210
    • Shannon Nelson's avatar
      ionic: add helpers for accessing buffer info · 97538c14
      Shannon Nelson authored
      These helpers clean up some of the code around DMA mapping
      and other buffer references, and will be used in the next
      few patches for the XDP support.
      Signed-off-by: default avatarShannon Nelson <shannon.nelson@amd.com>
      Reviewed-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97538c14
    • Shannon Nelson's avatar
      ionic: set adminq irq affinity · c699f35d
      Shannon Nelson authored
      We claim to have the AdminQ on our irq0 and thus cpu id 0,
      but we need to be sure we set the affinity hint to try to
      keep it there.
      Signed-off-by: default avatarShannon Nelson <shannon.nelson@amd.com>
      Reviewed-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c699f35d
    • Alexander Gordeev's avatar
      net/iucv: fix virtual vs physical address confusion · 2210c548
      Alexander Gordeev authored
      Fix virtual vs physical address confusion. This does not fix a bug
      since virtual and physical address spaces are currently the same.
      Acked-by: default avatarAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: default avatarAlexander Gordeev <agordeev@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2210c548
    • David S. Miller's avatar
      Merge branch 'ravb-rutime-PM-support' · fc136368
      David S. Miller authored
      Claudiu Beznea says:
      
      ====================
      net: ravb: Add runtime PM support (part 2)
      
      Series adds runtime PM support for the ravb driver. This is a continuation
      of [1].
      
      There are 5 more preparation patches (patches 1-5) and patch 6
      adds runtime PM support.
      
      Patches in this series were part of [2].
      
      Changes in v4:
      - remove unnecessary code from patch 4/6
      - improve the code in patch 5/6
      
      Changes in v3:
      - fixed typos
      - added patch "net: ravb: Move the update of ndev->features to
        ravb_set_features()"
      - changes title of patch "net: ravb: Do not apply RX checksum
        settings to hardware if the interface is down" from v2 into
        "net: ravb: Do not apply features to hardware if the interface
        is down", changed patch description and updated the patch
      - collected tags
      
      Changes in v2:
      - address review comments
      - in patch 4/5 take into account the latest changes introduced
        in ravb_set_features_gbeth()
      
      Changes since [2]:
      - patch 1/5 is new
      - use pm_runtime_get_noresume() and pm_runtime_active() in patches
        3/5, 4/5
      - fixed higlighted typos in patch 4/5
      
      [1] https://lore.kernel.org/all/20240202084136.3426492-1-claudiu.beznea.uj@bp.renesas.com/
      [2] https://lore.kernel.org/all/20240105082339.1468817-1-claudiu.beznea.uj@bp.renesas.com/
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fc136368
    • Claudiu Beznea's avatar
      net: ravb: Add runtime PM support · 48f894ab
      Claudiu Beznea authored
      Add runtime PM support for the ravb driver. As the driver is used by
      different IP variants, with different behaviors, to be able to have the
      runtime PM support available for all devices, the preparatory commits
      moved all the resources parsing and allocations in the driver's probe
      function and kept the settings for ravb_open(). This is due to the fact
      that on some IP variants-platforms tuples disabling/enabling the clocks
      will switch the IP to the reset operation mode where register contents is
      lost and reconfiguration needs to be done. For this the rabv_open()
      function enables the clocks, switches the IP to configuration mode, applies
      all the register settings and switches the IP to the operational mode. At
      the end of ravb_open() IP is ready to send/receive data.
      
      In ravb_close() necessary reverts are done (compared with ravb_open()), the
      IP is switched to reset mode and clocks are disabled.
      
      The ethtool APIs or IOCTLs that might execute while the interface is down
      are either cached (and applied in ravb_open()) or rejected (as at that time
      the IP is in reset mode). Keeping the IP in the reset mode also increases
      the power saved (according to the hardware manual).
      Signed-off-by: default avatarClaudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
      Reviewed-by: default avatarSergey Shtylyov <s.shtylyov@omp.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48f894ab
    • Claudiu Beznea's avatar
      net: ravb: Do not apply features to hardware if the interface is down · a71a50e3
      Claudiu Beznea authored
      Do not apply features to hardware if the interface is down. In case runtime
      PM is enabled, and while the interface is down, the IP will be in reset
      mode (as for some platforms disabling the clocks will switch the IP to
      reset mode, which will lead to losing register contents) and applying
      settings in reset mode is not an option. Instead, cache the features and
      apply them in ravb_open() through ravb_emac_init().
      
      To avoid accessing the hardware while the interface is down
      pm_runtime_active() check was introduced. Along with it the device runtime
      PM usage counter has been incremented to avoid disabling the device clocks
      while the check is in progress (if any).
      
      Commit prepares for the addition of runtime PM.
      Signed-off-by: default avatarClaudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
      Reviewed-by: default avatarSergey Shtylyov <s.shtylyov@omp.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a71a50e3
    • Claudiu Beznea's avatar
      net: ravb: Move the update of ndev->features to ravb_set_features() · 7bddccc9
      Claudiu Beznea authored
      Commit c2da9408 ("ravb: Add Rx checksum offload support for GbEth")
      introduced support for setting GbEth features. With this the IP-specific
      features update functions update the ndev->features individually.
      
      Next commits add runtime PM support for the ravb driver. The runtime PM
      implementation will enable/disable the IP clocks on
      the ravb_open()/ravb_close() functions. Accessing the IP registers with
      clocks disabled blocks the system.
      
      The ravb_set_features() function could be executed when the Ethernet
      interface is closed so we need to ensure we don't access IP registers while
      the interface is down when runtime PM support will be in place.
      
      For these, move the update of ndev->features to ravb_set_features(). In
      this way we update the ndev->features only when the IP-specific features
      set function returns success and we can avoid code duplication when
      introducing runtime PM registers protection.
      Signed-off-by: default avatarClaudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
      Reviewed-by: default avatarSergey Shtylyov <s.shtylyov@omp.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7bddccc9
    • Claudiu Beznea's avatar
      net: ravb: Return cached statistics if the interface is down · bbf2345f
      Claudiu Beznea authored
      Return the cached statistics in case the interface is down. There should be
      no drawback to this, as cached statistics are updated in ravb_close().
      
      In order to avoid accessing the IP registers while the IP is runtime
      suspended pm_runtime_active() check was introduced. The device runtime
      PM usage counter has been incremented to avoid disabling the device clocks
      while the check is in progress (if any).
      
      The commit prepares the code for the addition of runtime PM support.
      Suggested-by: default avatarSergey Shtylyov <s.shtylyov@omp.ru>
      Signed-off-by: default avatarClaudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
      Reviewed-by: default avatarSergey Shtylyov <s.shtylyov@omp.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bbf2345f
    • Claudiu Beznea's avatar
      net: ravb: Keep the reverse order of operations in ravb_close() · a5f149a9
      Claudiu Beznea authored
      Keep the reverse order of operations in ravb_close() when compared with
      ravb_open(). This is the recommended configuration sequence.
      Signed-off-by: default avatarClaudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
      Reviewed-by: default avatarSergey Shtylyov <s.shtylyov@omp.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5f149a9
    • Claudiu Beznea's avatar
      net: ravb: Get rid of the temporary variable irq · a260f080
      Claudiu Beznea authored
      The 4th argument of ravb_setup_irq() is used to save the IRQ number that
      will be further used by the driver code. Not all ravb_setup_irqs() calls
      need to save the IRQ number. The previous code used to pass a dummy
      variable as the 4th argument in case the IRQ is not needed for further
      usage. That is not necessary as the code from ravb_setup_irq() can detect
      by itself if the IRQ needs to be saved. Thus, get rid of the code that is
      not needed.
      Reported-by: default avatarSergey Shtylyov <s.shtylyov@omp.ru>
      Signed-off-by: default avatarClaudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
      Reviewed-by: default avatarSergey Shtylyov <s.shtylyov@omp.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a260f080
    • Hangbin Liu's avatar
      selftests: bonding: make sure new active is not null · 31f26e4f
      Hangbin Liu authored
      One of Jakub's tests[1] shows that there may be period all ports
      are down and no active slave. This makes the new_active_slave null
      and the test fails. Add a check to make sure the new active is not null.
      
       [  189.051966] br0: port 2(s1) entered disabled state
       [  189.317881] bond0: (slave eth1): link status definitely down, disabling slave
       [  189.318487] bond0: (slave eth2): making interface the new active one
       [  190.435430] br0: port 4(s2) entered disabled state
       [  190.773786] bond0: (slave eth0): link status definitely down, disabling slave
       [  190.774204] bond0: (slave eth2): link status definitely down, disabling slave
       [  190.774715] bond0: now running without any active interface!
       [  190.877760] bond0: (slave eth0): link status definitely up
       [  190.878098] bond0: (slave eth0): making interface the new active one
       [  190.878495] bond0: active interface up!
       [  191.802872] br0: port 4(s2) entered blocking state
       [  191.803157] br0: port 4(s2) entered forwarding state
       [  191.813756] bond0: (slave eth2): link status definitely up
       [  192.847095] br0: port 2(s1) entered blocking state
       [  192.847396] br0: port 2(s1) entered forwarding state
       [  192.853740] bond0: (slave eth1): link status definitely up
       # TEST: prio (active-backup ns_ip6_target primary_reselect 1)         [FAIL]
       # Current active slave is null but not eth0
      
      [1] https://netdev-3.bots.linux.dev/vmksft-bonding/results/464481/1-bond-options-sh/stdout
      
      Fixes: 45bf79bc ("selftests: bonding: reduce garp_test/arp_validate test time")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31f26e4f
    • Arınç ÜNAL's avatar
      net: dsa: remove OF-based MDIO bus registration from DSA core · ae94dc25
      Arınç ÜNAL authored
      The code block under the "!ds->user_mii_bus && ds->ops->phy_read" check
      under dsa_switch_setup() populates ds->user_mii_bus. The use of
      ds->user_mii_bus is inappropriate when the MDIO bus of the switch is
      described on the device tree [1].
      
      For this reason, use this code block only for switches [with MDIO bus]
      probed on platform_data, and OF which the switch MDIO bus isn't described
      on the device tree. Therefore, remove OF-based MDIO bus registration as
      it's useless for these cases.
      
      These subdrivers which control switches [with MDIO bus] probed on OF, will
      lose the ability to register the MDIO bus OF-based:
      
      drivers/net/dsa/b53/b53_common.c
      drivers/net/dsa/lan9303-core.c
      drivers/net/dsa/vitesse-vsc73xx-core.c
      
      These subdrivers let the DSA core driver register the bus:
      - ds->ops->phy_read() and ds->ops->phy_write() are present.
      - ds->user_mii_bus is not populated.
      
      The commit fe7324b9 ("net: dsa: OF-ware slave_mii_bus") which brought
      OF-based MDIO bus registration on the DSA core driver is reasonably recent
      and, in this time frame, there have been no device trees in the Linux
      repository that started describing the MDIO bus, or dt-bindings defining
      the MDIO bus for the switches these subdrivers control. So I don't expect
      any devices to be affected.
      
      The logic we encourage is that all subdrivers should register the switch
      MDIO bus on their own [2]. And, for subdrivers which control switches [with
      MDIO bus] probed on OF, this logic must be followed to support all cases
      properly:
      
      No switch MDIO bus defined: Populate ds->user_mii_bus, register the MDIO
      bus, set the interrupts for PHYs if "interrupt-controller" is defined at
      the switch node. This case should only be covered for the switches which
      their dt-bindings documentation didn't document the MDIO bus from the
      start. This is to keep supporting the device trees that do not describe the
      MDIO bus on the device tree but the MDIO bus is being used nonetheless.
      
      Switch MDIO bus defined: Don't populate ds->user_mii_bus, register the MDIO
      bus, set the interrupts for PHYs if ["interrupt-controller" is defined at
      the switch node and "interrupts" is defined at the PHY nodes under the
      switch MDIO bus node].
      
      Switch MDIO bus defined but explicitly disabled: If the device tree says
      status = "disabled" for the MDIO bus, we shouldn't need an MDIO bus at all.
      Instead, just exit as early as possible and do not call any MDIO API.
      
      After all subdrivers that control switches with MDIO buses are made to
      register the MDIO buses on their own, we will be able to get rid of
      dsa_switch_ops :: phy_read() and :: phy_write(), and the code block for
      registering the MDIO bus on the DSA core driver.
      
      Link: https://lore.kernel.org/netdev/20231213120656.x46fyad6ls7sqyzv@skbuf/ [1]
      Link: https://lore.kernel.org/netdev/20240103184459.dcbh57wdnlox6w7d@skbuf/ [2]
      Suggested-by: default avatarLuiz Angelo Daros de Luca <luizluca@gmail.com>
      Acked-by: default avatarLuiz Angelo Daros de Luca <luizluca@gmail.com>
      Signed-off-by: default avatarArınç ÜNAL <arinc.unal@arinc9.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Link: https://lore.kernel.org/r/20240213-for-netnext-dsa-mdio-bus-v2-1-0ff6f4823a9e@arinc9.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ae94dc25