1. 12 3月, 2022 4 次提交
  2. 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
  3. 20 11月, 2020 1 次提交
    • J
      devlink: move request_firmware out of driver · b44cfd4f
      Jacob Keller 提交于
      All drivers which implement the devlink flash update support, with the
      exception of netdevsim, use either request_firmware or
      request_firmware_direct to locate the firmware file. Rather than having
      each driver do this separately as part of its .flash_update
      implementation, perform the request_firmware within net/core/devlink.c
      
      Replace the file_name parameter in the struct devlink_flash_update_params
      with a pointer to the fw object.
      
      Use request_firmware rather than request_firmware_direct. Although most
      Linux distributions today do not have the fallback mechanism
      implemented, only about half the drivers used the _direct request, as
      compared to the generic request_firmware. In the event that
      a distribution does support the fallback mechanism, the devlink flash
      update ought to be able to use it to provide the firmware contents. For
      distributions which do not support the fallback userspace mechanism,
      there should be essentially no difference between request_firmware and
      request_firmware_direct.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Acked-by: NShannon Nelson <snelson@pensando.io>
      Acked-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      b44cfd4f
  4. 13 11月, 2020 1 次提交
  5. 22 4月, 2020 1 次提交
  6. 11 9月, 2019 2 次提交
  7. 27 8月, 2019 1 次提交
  8. 15 6月, 2019 1 次提交
  9. 27 4月, 2019 1 次提交
  10. 18 2月, 2019 1 次提交
  11. 12 10月, 2018 1 次提交
  12. 29 8月, 2018 4 次提交
  13. 26 7月, 2018 1 次提交
  14. 30 6月, 2018 1 次提交
    • J
      nfp: stop limiting VFs to 0 · 83235822
      Jakub Kicinski 提交于
      Before 8d85a7a4 ("PCI/IOV: Allow PF drivers to limit total_VFs to 0"),
      pci_sriov_set_totalvfs(pdev, 0) meant "we can enable TotalVFs virtual
      functions".  After 8d85a7a4, it means "we can't enable *any* VFs".
      
      That broke this scenario where nfp intends to remove any limit on the
      number of VFs that can be enabled:
      
        nfp_pci_probe
          nfp_pcie_sriov_read_nfd_limit
            nfp_rtsym_read_le("nfd_vf_cfg_max_vfs", &err)
            pci_sriov_set_totalvfs(pf->pdev, 0)   # if FW didn't expose a limit
      
        ...
        # userspace writes N to sysfs "sriov_numvfs":
        sriov_numvfs_store
          pci_sriov_get_totalvfs                  # now returns 0
          return -ERANGE
      
      Prior to 8d85a7a4, pci_sriov_get_totalvfs() returned TotalVFs, but it
      now returns 0.
      
      Remove the pci_sriov_set_totalvfs(pdev, 0) calls so we don't limit the
      number of VFs that can be enabled.
      
      Fixes: 8d85a7a4 ("PCI/IOV: Allow PF drivers to limit total_VFs to 0")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      [bhelgaas: changelog]
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      83235822
  15. 24 5月, 2018 2 次提交
  16. 26 4月, 2018 1 次提交
  17. 23 2月, 2018 1 次提交
  18. 08 2月, 2018 1 次提交
  19. 23 1月, 2018 1 次提交
  20. 20 1月, 2018 1 次提交
    • J
      nfp: register devlink after app is created · bcc93a23
      Jakub Kicinski 提交于
      Devlink used to have two global locks: devlink lock and port lock,
      our lock ordering looked like this:
      
        devlink lock -> driver's pf->lock -> devlink port lock
      
      After recent changes port lock was replaced with per-instance
      lock.  Unfortunately, new per-instance lock is taken on most
      operations now.  This means we can only grab the pf->lock from
      the port split/unsplit ops.  Lock ordering looks like this:
      
        devlink lock -> driver's pf->lock -> devlink instance lock
      
      Since we can't take pf->lock from most devlink ops, make sure
      nfp_apps are prepared to service them as soon as devlink is
      registered.  Locking the pf must be pushed down after
      nfp_app_init() callback.
      
      The init order looks like this:
       nfp_app_init
       devlink_register
       nfp_app_start
       netdev/port_register
      
      As soon as app_init is done nfp_apps must be ready to service
      devlink-related callbacks.  apps can only register their own
      devlink objects from nfp_app_start.
      
      Fixes: 2406e7e5 ("devlink: Add per devlink instance lock")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bcc93a23
  21. 06 12月, 2017 1 次提交
  22. 05 11月, 2017 1 次提交
  23. 14 9月, 2017 2 次提交
  24. 24 8月, 2017 1 次提交
  25. 28 7月, 2017 2 次提交
    • J
      nfp: only use direct firmware requests · 1680a370
      Jakub Kicinski 提交于
      request_firmware() will fallback to user space helper and may cause
      long delays when driver is loaded if udev doesn't correctly handle
      FW requests.  Since we never really made use of the user space
      helper functionality switch to the simpler request_firmware_direct()
      call.  The side effect of this change is that no warning will be
      printed when the FW image does not exists.  To help users figure
      out which FW file is missing print a info message when we request
      each file.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1680a370
    • J
      nfp: look for firmware image by device serial number and PCI name · 9511f298
      Jakub Kicinski 提交于
      We generally look up firmware by card type, but that doesn't allow
      users who have more than one card of the same type in their system
      to select firmware per adapter.
      
      Unfortunately user space firmware helper seems fraught with
      difficulties and to be on its way out.  In particular support for
      handling firmware uevents have been dropped from systemd and most
      distributions don't enable the FW fallback by default any more.
      
      To allow users selecting firmware for a particular device look up
      firmware names by serial and pci_name().  Use the direct lookup to
      disable generating uevents when enabled in Kconfig and not print
      any warnings to logs if adapter-specific files are missing.  Users
      can place in /lib/firmware/netronome files named:
      
      pci-${pci_name}.nffw
      serial-${serial}.nffw
      
      to target a specific card.  E.g.:
      
      pci-0000:04:00.0.nffw
      pci-0000:82:00.0.nffw
      serial-00-aa-bb-11-22-33-10-ff.nffw
      
      We use the full serial number including the interface id, as it
      appears in lspci output (bytes separated by '-').
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9511f298
  26. 28 6月, 2017 3 次提交
  27. 25 6月, 2017 1 次提交
  28. 10 6月, 2017 1 次提交