1. 02 11月, 2021 1 次提交
  2. 01 11月, 2021 4 次提交
  3. 30 10月, 2021 1 次提交
  4. 13 10月, 2021 2 次提交
    • L
      devlink: Delete reload enable/disable interface · 82465bec
      Leon Romanovsky 提交于
      Commit a0c76345 ("devlink: disallow reload operation during device
      cleanup") added devlink_reload_{enable,disable}() APIs to prevent reload
      operation from racing with device probe/dismantle.
      
      After recent changes to move devlink_register() to the end of device
      probe and devlink_unregister() to the beginning of device dismantle,
      these races can no longer happen. Reload operations will be denied if
      the devlink instance is unregistered and devlink_unregister() will block
      until all in-flight operations are done.
      
      Therefore, remove these devlink_reload_{enable,disable}() APIs.
      Signed-off-by: NLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      82465bec
    • L
      devlink: Allow control devlink ops behavior through feature mask · bd032e35
      Leon Romanovsky 提交于
      Introduce new devlink call to set feature mask to control devlink
      behavior during device initialization phase after devlink_alloc()
      is already called.
      
      This allows us to set reload ops based on device property which
      is not known at the beginning of driver initialization.
      
      For the sake of simplicity, this API lacks any type of locking and
      needs to be called before devlink_register() to make sure that no
      parallel access to the ops is possible at this stage.
      Signed-off-by: NLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      bd032e35
  5. 27 9月, 2021 1 次提交
  6. 22 9月, 2021 1 次提交
  7. 09 8月, 2021 1 次提交
    • L
      devlink: Set device as early as possible · 919d13a7
      Leon Romanovsky 提交于
      All kernel devlink implementations call to devlink_alloc() during
      initialization routine for specific device which is used later as
      a parent device for devlink_register().
      
      Such late device assignment causes to the situation which requires us to
      call to device_register() before setting other parameters, but that call
      opens devlink to the world and makes accessible for the netlink users.
      
      Any attempt to move devlink_register() to be the last call generates the
      following error due to access to the devlink->dev pointer.
      
      [    8.758862]  devlink_nl_param_fill+0x2e8/0xe50
      [    8.760305]  devlink_param_notify+0x6d/0x180
      [    8.760435]  __devlink_params_register+0x2f1/0x670
      [    8.760558]  devlink_params_register+0x1e/0x20
      
      The simple change of API to set devlink device in the devlink_alloc()
      instead of devlink_register() fixes all this above and ensures that
      prior to call to devlink_register() everything already set.
      Signed-off-by: NLeon Romanovsky <leonro@nvidia.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      919d13a7
  8. 06 8月, 2021 1 次提交
  9. 05 8月, 2021 1 次提交
  10. 31 7月, 2021 1 次提交
  11. 19 6月, 2021 1 次提交
  12. 15 6月, 2021 1 次提交
  13. 10 6月, 2021 1 次提交
  14. 03 6月, 2021 9 次提交
  15. 15 3月, 2021 1 次提交
    • I
      netdevsim: Add dummy psample implementation · a8700c3d
      Ido Schimmel 提交于
      Allow netdevsim to report "sampled" packets to the psample module by
      periodically generating packets from a work queue. The behavior can be
      enabled / disabled (default) and the various meta data attributes can be
      controlled via debugfs knobs.
      
      This implementation enables both testing of the psample module with all
      the optional attributes as well as development of user space
      applications on top of psample such as hsflowd and a Wireshark dissector
      for psample generic netlink packets.
      Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8700c3d
  16. 09 2月, 2021 1 次提交
  17. 20 11月, 2020 1 次提交
    • J
      devlink: move flash end and begin to core devlink · 52cc5f3a
      Jacob Keller 提交于
      When performing a flash update via devlink, device drivers may inform
      user space of status updates via
      devlink_flash_update_(begin|end|timeout|status)_notify functions.
      
      It is expected that drivers do not send any status notifications unless
      they send a begin and end message. If a driver sends a status
      notification without sending the appropriate end notification upon
      finishing (regardless of success or failure), the current implementation
      of the devlink userspace program can get stuck endlessly waiting for the
      end notification that will never come.
      
      The current ice driver implementation may send such a status message
      without the appropriate end notification in rare cases.
      
      Fixing the ice driver is relatively simple: we just need to send the
      begin_notify at the start of the function and always send an end_notify
      no matter how the function exits.
      
      Rather than assuming driver authors will always get this right in the
      future, lets just fix the API so that it is not possible to get wrong.
      Make devlink_flash_update_begin_notify and
      devlink_flash_update_end_notify static, and call them in devlink.c core
      code. Always send the begin_notify just before calling the driver's
      flash_update routine. Always send the end_notify just after the routine
      returns regardless of success or failure.
      
      Doing this makes the status notification easier to use from the driver,
      as it no longer needs to worry about catching failures and cleaning up
      by calling devlink_flash_update_end_notify. It is now no longer possible
      to do the wrong thing in this regard. We also save a couple of lines of
      code in each driver.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Acked-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      52cc5f3a
  18. 18 11月, 2020 1 次提交
  19. 07 11月, 2020 1 次提交
    • I
      netdevsim: Add devlink resource for nexthops · 35266255
      Ido Schimmel 提交于
      The Spectrum ASIC has a dedicated table where nexthops (i.e., adjacency
      entries) are populated. The size of this table can be controlled via
      devlink-resource.
      
      Add such a resource to netdevsim so that its occupancy will reflect the
      number of nexthop objects currently programmed to the device.
      
      By limiting the size of the resource, error paths could be exercised and
      tested.
      
      Example output:
      
      # devlink resource show netdevsim/netdevsim10
      netdevsim/netdevsim10:
        name IPv4 size unlimited unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none
          resources:
            name fib size unlimited occ 4 unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none
            name fib-rules size unlimited occ 3 unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none
        name IPv6 size unlimited unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none
          resources:
            name fib size unlimited occ 1 unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none
            name fib-rules size unlimited occ 2 unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none
        name nexthops size unlimited occ 0 unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none
      Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      35266255
  20. 10 10月, 2020 2 次提交
    • M
      devlink: Add devlink reload limit option · dc64cc7c
      Moshe Shemesh 提交于
      Add reload limit to demand restrictions on reload actions.
      Reload limits supported:
      no_reset: No reset allowed, no down time allowed, no link flap and no
                configuration is lost.
      
      By default reload limit is unspecified and so no constraints on reload
      actions are required.
      
      Some combinations of action and limit are invalid. For example, driver
      can not reinitialize its entities without any downtime.
      
      The no_reset reload limit will have usecase in this patchset to
      implement restricted fw_activate on mlx5.
      
      Have the uapi parameter of reload limit ready for future support of
      multiselection.
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      dc64cc7c
    • M
      devlink: Add reload action option to devlink reload command · ccdf0721
      Moshe Shemesh 提交于
      Add devlink reload action to allow the user to request a specific reload
      action. The action parameter is optional, if not specified then devlink
      driver re-init action is used (backward compatible).
      Note that when required to do firmware activation some drivers may need
      to reload the driver. On the other hand some drivers may need to reset
      the firmware to reinitialize the driver entities. Therefore, the devlink
      reload command returns the actions which were actually performed.
      Reload actions supported are:
      driver_reinit: driver entities re-initialization, applying devlink-param
                     and devlink-resource values.
      fw_activate: firmware activate.
      
      command examples:
      $devlink dev reload pci/0000:82:00.0 action driver_reinit
      reload_actions_performed:
        driver_reinit
      
      $devlink dev reload pci/0000:82:00.0 action fw_activate
      reload_actions_performed:
        driver_reinit fw_activate
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      ccdf0721
  21. 26 9月, 2020 3 次提交
    • J
      netdevsim: add support for flash_update overwrite mask · cbb58368
      Jacob Keller 提交于
      The devlink interface recently gained support for a new "overwrite mask"
      parameter that allows specifying how various sub-sections of a flash
      component are modified when updating.
      
      Add support for this to netdevsim, to enable easily testing the
      interface. Make the allowed overwrite mask values controllable via
      a debugfs parameter. This enables testing a flow where the driver
      rejects an unsupportable overwrite mask.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cbb58368
    • J
      devlink: convert flash_update to use params structure · bc75c054
      Jacob Keller 提交于
      The devlink core recently gained support for checking whether the driver
      supports a flash_update parameter, via `supported_flash_update_params`.
      However, parameters are specified as function arguments. Adding a new
      parameter still requires modifying the signature of the .flash_update
      callback in all drivers.
      
      Convert the .flash_update function to take a new `struct
      devlink_flash_update_params` instead. By using this structure, and the
      `supported_flash_update_params` bit field, a new parameter to
      flash_update can be added without requiring modification to existing
      drivers.
      
      As before, all parameters except file_name will require driver opt-in.
      Because file_name is a necessary field to for the flash_update to make
      sense, no "SUPPORTED" bitflag is provided and it is always considered
      valid. All future additional parameters will require a new bit in the
      supported_flash_update_params bitfield.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Cc: Bin Luo <luobin9@huawei.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: Danielle Ratson <danieller@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc75c054
    • J
      devlink: check flash_update parameter support in net core · 22ec3d23
      Jacob Keller 提交于
      When implementing .flash_update, drivers which do not support
      per-component update are manually checking the component parameter to
      verify that it is NULL. Without this check, the driver might accept an
      update request with a component specified even though it will not honor
      such a request.
      
      Instead of having each driver check this, move the logic into
      net/core/devlink.c, and use a new `supported_flash_update_params` field
      in the devlink_ops. Drivers which will support per-component update must
      now specify this by setting DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT in
      the supported_flash_update_params in their devlink_ops.
      
      This helps ensure that drivers do not forget to check for a NULL
      component if they do not support per-component update. This also enables
      a slightly better error message by enabling the core stack to set the
      netlink bad attribute message to indicate precisely the unsupported
      attribute in the message.
      
      Going forward, any new additional parameter to flash update will require
      a bit in the supported_flash_update_params bitfield.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Cc: Bin Luo <luobin9@huawei.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: Danielle Ratson <danieller@mellanox.com>
      Cc: Shannon Nelson <snelson@pensando.io>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22ec3d23
  22. 19 9月, 2020 2 次提交
  23. 04 8月, 2020 1 次提交
  24. 11 7月, 2020 1 次提交