1. 30 4月, 2019 1 次提交
    • P
      net/mlx5: Get rid of storing copy of device name · 27b942fb
      Parav Pandit 提交于
      Currently mlx5 core stores copy of the PCI device name in a
      mlx5_priv structure and uses pr_warn, pr_err helpers.
      
      Get rid of the copy of this name; instead store the parent device
      pointer that contains name as well as dma specific parameters.
      This also allows to use kernel's well defined dev_warn, dev_err, dev_dbg
      device specific print routines.
      
      This is also a preparation patch to access non PCI parent device in
      future.
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      27b942fb
  2. 03 4月, 2019 3 次提交
  3. 02 3月, 2019 2 次提交
  4. 16 2月, 2019 1 次提交
  5. 15 2月, 2019 4 次提交
    • B
      net/mlx5: Relocate vport macros to the vport header file · bf3e4d38
      Bodong Wang 提交于
      These are two macros in the driver general header which deal with the
      number of total vports and if a vport is vport manager. Such macros
      are vport entities, better to place them at the vport header file.
      
      This patch doesn't change any functionality.
      Signed-off-by: NBodong Wang <bodong@mellanox.com>
      Reviewed-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      bf3e4d38
    • B
      net/mlx5: Provide an alternative VF upper bound for ECPF · feb39369
      Bodong Wang 提交于
      ECPF doesn't support SR-IOV, but an ECPF E-Switch manager shall know
      the max VFs supported by its peer host PF in order to control those
      VF vports.
      
      The current driver implementation uses the total vfs quantity as
      provided by the pci sub-system for an upper bound of the VF vports
      the e-switch code needs to deal with. This obviously can't work as
      is on ECPF e-switch manager. For now, we use a hard coded value of
      128 on such systems.
      Signed-off-by: NBodong Wang <bodong@mellanox.com>
      Reviewed-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      feb39369
    • B
      net/mlx5: Add host params change event · 7f0d11c7
      Bodong Wang 提交于
      In Embedded CPU (EC) configurations, the EC driver needs to know when
      the number of virtual functions change on the corresponding PF at the
      host side. This is required so the EC driver can create or destroy
      representor net devices that represent the VFs ports.
      
      Whenever a change in the number of VFs occurs, firmware will generate an
      event towards the EC which will trigger a work to complete the rest of
      the handling. The specifics of the handling will be introduced in a
      downstream patch.
      Signed-off-by: NBodong Wang <bodong@mellanox.com>
      Signed-off-by: NEli Cohen <eli@mellanox.com>
      Reviewed-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      7f0d11c7
    • B
      net/mlx5: Introduce Mellanox SmartNIC and modify page management logic · 591905ba
      Bodong Wang 提交于
      Mellanox's SmartNIC combines embedded CPU(e.g, ARM) processing power
      with advanced network offloads to accelerate a multitude of security,
      networking and storage applications.
      
      With the introduction of the SmartNIC, there is a new PCI function
      called Embedded CPU Physical Function(ECPF). And it's possible for a
      PF to get its ICM pages from the ECPF PCI function. Driver shall
      identify if it is running on such a function by reading a bit in
      the initialization segment.
      
      When firmware asks for pages, it would issue a page request event
      specifying how many pages it requests and for which function. That
      driver responds with a manage_pages command providing the requested
      pages along with an indication for which function it is providing these
      pages.
      
      The encoding before this patch was as follows:
          function_id == 0: pages are requested for the function receiving
                            the EQE.
          function_id != 0: pages are requested for VF identified by the
                            function_id value
      
      A new one bit field in the EQE identifies that pages are requested for
      the ECPF.
      
      The notion of page_supplier can be introduced here and to support that,
      manage pages and query pages were modified so firmware can distinguish
      the following cases:
      
      1. Function provides pages for itself
      2. PF provides pages for its VF
      3. ECPF provides pages to itself
      4. ECPF provides pages for another function
      
      This distinction is possible through the introduction of the bit
      "embedded_cpu_function" in query_pages, manage_pages and page request
      EQE.
      Signed-off-by: NBodong Wang <bodong@mellanox.com>
      Signed-off-by: NEli Cohen <eli@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      591905ba
  6. 24 1月, 2019 1 次提交
  7. 22 1月, 2019 1 次提交
  8. 15 1月, 2019 1 次提交
  9. 09 1月, 2019 1 次提交
  10. 15 12月, 2018 2 次提交
  11. 12 12月, 2018 1 次提交
  12. 11 12月, 2018 1 次提交
  13. 04 12月, 2018 2 次提交
  14. 30 11月, 2018 6 次提交
  15. 27 11月, 2018 5 次提交
  16. 21 11月, 2018 8 次提交