1. 15 10月, 2017 1 次提交
  2. 25 8月, 2017 1 次提交
  3. 23 8月, 2017 1 次提交
  4. 14 5月, 2017 1 次提交
  5. 22 4月, 2017 2 次提交
  6. 10 1月, 2017 2 次提交
    • E
      IB/mlx5: Allow future extension of libmlx5 input data · b037c29a
      Eli Cohen 提交于
      Current check requests that new fields in struct
      mlx5_ib_alloc_ucontext_req_v2 that are not known to the driver be zero.
      This was introduced so new libraries passing additional information to
      the kernel through struct mlx5_ib_alloc_ucontext_req_v2 will be notified
      by old kernels that do not support their request by failing the
      operation. This schecme is problematic since it requires libmlx5 to issue
      the requests with descending input size for struct
      mlx5_ib_alloc_ucontext_req_v2.
      
      To avoid this, we require that new features that will obey the following
      rules:
      If the feature requires one or more fields in the response and the at
      least one of the fields can be encoded such that a zero value means the
      kernel ignored the request then this field will provide the indication
      to the library. If no response is required or if zero is a valid
      response, a new field should be added that indicates to the library
      whether its request was processed.
      
      Fixes: b368d7cb ('IB/mlx5: Add hca_core_clock_offset to udata in init_ucontext')
      Signed-off-by: NEli Cohen <eli@mellanox.com>
      Reviewed-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      b037c29a
    • E
      IB/mlx5: Use blue flame register allocator in mlx5_ib · 5fe9dec0
      Eli Cohen 提交于
      Make use of the blue flame registers allocator at mlx5_ib. Since blue
      flame was not really supported we remove all the code that is related to
      blue flame and we let all consumers to use the same blue flame register.
      Once blue flame is supported we will add the code. As part of this patch
      we also move the definition of struct mlx5_bf to mlx5_ib.h as it is only
      used by mlx5_ib.
      Signed-off-by: NEli Cohen <eli@mellanox.com>
      Reviewed-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      5fe9dec0
  7. 08 1月, 2017 1 次提交
  8. 14 12月, 2016 1 次提交
  9. 17 11月, 2016 2 次提交
  10. 08 10月, 2016 1 次提交
  11. 03 9月, 2016 1 次提交
  12. 14 8月, 2016 1 次提交
  13. 23 6月, 2016 1 次提交
    • M
      IB/mlx5: Reset flow support for IB kernel ULPs · 89ea94a7
      Maor Gottlieb 提交于
      The driver exposes interfaces that directly relate to HW state.
      Upon fatal error, consumers of these interfaces (ULPs) that rely
      on completion of all their posted work-request could hang, thereby
      introducing dependencies in shutdown order. To prevent this from
      happening, we manage the relevant resources (CQs, QPs) that are used
      by the device. Upon a fatal error, we now generate simulated
      completions for outstanding WQEs that were not completed at the
      time the HW was reset.
      
      It includes invoking the completion event handler for all involved
      CQs so that the ULPs will poll those CQs. When polled we return
      simulated CQEs with IB_WC_WR_FLUSH_ERR return code enabling ULPs
      to clean up their  resources and not wait forever for completions
      upon receiving remove_one.
      
      The above change requires an extra check in the data path to make
      sure that when device is in error state, the simulated CQEs will
      be returned and no further WQEs will be posted.
      Signed-off-by: NMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      89ea94a7
  14. 07 6月, 2016 2 次提交
  15. 18 5月, 2016 1 次提交
  16. 02 3月, 2016 2 次提交
  17. 01 3月, 2016 1 次提交
  18. 22 1月, 2016 1 次提交
  19. 18 1月, 2016 1 次提交
    • D
      net/mlx5_core: Fix trimming down IRQ number · 0b6e26ce
      Doron Tsur 提交于
      With several ConnectX-4 cards installed on a server, one may receive
      irqn > 255 from the kernel API, which we mistakenly trim to 8bit.
      
      This causes EQ creation failure with the following stack trace:
      [<ffffffff812a11f4>] dump_stack+0x48/0x64
      [<ffffffff810ace21>] __setup_irq+0x3a1/0x4f0
      [<ffffffff810ad7e0>] request_threaded_irq+0x120/0x180
      [<ffffffffa0923660>] ? mlx5_eq_int+0x450/0x450 [mlx5_core]
      [<ffffffffa0922f64>] mlx5_create_map_eq+0x1e4/0x2b0 [mlx5_core]
      [<ffffffffa091de01>] alloc_comp_eqs+0xb1/0x180 [mlx5_core]
      [<ffffffffa091ea99>] mlx5_dev_init+0x5e9/0x6e0 [mlx5_core]
      [<ffffffffa091ec29>] init_one+0x99/0x1c0 [mlx5_core]
      [<ffffffff812e2afc>] local_pci_probe+0x4c/0xa0
      
      Fixing it by changing of the irqn type from u8 to unsigned int to
      support values > 255
      
      Fixes: 61d0e73e ('net/mlx5_core: Use the the real irqn in eq->irqn')
      Reported-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDoron Tsur <doront@mellanox.com>
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b6e26ce
  20. 24 12月, 2015 4 次提交
  21. 29 10月, 2015 2 次提交
  22. 04 9月, 2015 1 次提交
  23. 13 6月, 2015 1 次提交
  24. 31 5月, 2015 2 次提交
  25. 03 4月, 2015 4 次提交
  26. 22 11月, 2014 1 次提交
  27. 04 10月, 2014 1 次提交