1. 22 4月, 2020 1 次提交
  2. 11 9月, 2019 2 次提交
  3. 27 8月, 2019 1 次提交
  4. 15 6月, 2019 1 次提交
  5. 27 4月, 2019 1 次提交
  6. 18 2月, 2019 1 次提交
  7. 12 10月, 2018 1 次提交
  8. 29 8月, 2018 4 次提交
  9. 26 7月, 2018 1 次提交
  10. 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
  11. 24 5月, 2018 2 次提交
  12. 26 4月, 2018 1 次提交
  13. 23 2月, 2018 1 次提交
  14. 08 2月, 2018 1 次提交
  15. 23 1月, 2018 1 次提交
  16. 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
  17. 06 12月, 2017 1 次提交
  18. 05 11月, 2017 1 次提交
  19. 14 9月, 2017 2 次提交
  20. 24 8月, 2017 1 次提交
  21. 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
  22. 28 6月, 2017 3 次提交
  23. 25 6月, 2017 1 次提交
  24. 10 6月, 2017 3 次提交
  25. 01 6月, 2017 1 次提交
  26. 30 5月, 2017 2 次提交
  27. 26 5月, 2017 2 次提交