1. 17 11月, 2016 2 次提交
  2. 08 10月, 2016 8 次提交
  3. 24 9月, 2016 1 次提交
  4. 17 9月, 2016 4 次提交
    • K
      IB/mlx4: Diagnostic HW counters are not supported in slave mode · 69d269d3
      Kamal Heib 提交于
      Modify the mlx4_ib_diag_counters() to avoid the following error in the
      hypervisor when the slave tries to query the hardware counters in SR-IOV
      mode.
      
      mlx4_core 0000:81:00.0: Unknown command:0x30 accepted from slave:1
      
      Fixes: 3f85f2aa ("IB/mlx4: Add diagnostic hardware counters")
      Signed-off-by: NKamal Heib <kamalh@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      69d269d3
    • J
      IB/mlx4: Use correct subnet-prefix in QP1 mads under SR-IOV · 8ec07bf8
      Jack Morgenstein 提交于
      When sending QP1 MAD packets which use a GRH, the source GID
      (which consists of the 64-bit subnet prefix, and the 64 bit port GUID)
      must be included in the packet GRH.
      
      For SR-IOV, a GID cache is used, since the source GID needs to be the
      slave's source GID, and not the Hypervisor's GID. This cache also
      included a subnet_prefix. Unfortunately, the subnet_prefix field in
      the cache was never initialized (to the default subnet prefix 0xfe80::0).
      As a result, this field remained all zeroes.  Therefore, when SR-IOV
      was active, all QP1 packets which included a GRH had a source GID
      subnet prefix of all-zeroes.
      
      However, the subnet-prefix should initially be 0xfe80::0 (the default
      subnet prefix). In addition, if OpenSM modifies a port's subnet prefix,
      the new subnet prefix must be used in the GRH when sending QP1 packets.
      To fix this we now initialize the subnet prefix in the SR-IOV GID cache
      to the default subnet prefix. We update the cached value if/when OpenSM
      modifies the port's subnet prefix. We take this cached value when sending
      QP1 packets when SR-IOV is active.
      
      Note that the value is stored as an atomic64. This eliminates any need
      for locking when the subnet prefix is being updated.
      
      Note also that we depend on the FW generating the "port management change"
      event for tracking subnet-prefix changes performed by OpenSM. If running
      early FW (before 2.9.4630), subnet prefix changes will not be tracked (but
      the default subnet prefix still will be stored in the cache; therefore
      users who do not modify the subnet prefix will not have a problem).
      IF there is a need for such tracking also for early FW, we will add that
      capability in a subsequent patch.
      
      Fixes: 1ffeb2eb ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      8ec07bf8
    • J
      IB/mlx4: Fix code indentation in QP1 MAD flow · baa0be70
      Jack Morgenstein 提交于
      The indentation in the QP1 GRH flow in procedure build_mlx_header is
      really confusing. Fix it, in preparation for a commit which touches
      this code.
      
      Fixes: 1ffeb2eb ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      baa0be70
    • A
      IB/mlx4: Fix incorrect MC join state bit-masking on SR-IOV · e5ac40cd
      Alex Vesker 提交于
      Because of an incorrect bit-masking done on the join state bits, when
      handling a join request we failed to detect a difference between the
      group join state and the request join state when joining as send only
      full member (0x8). This caused the MC join request not to be sent.
      This issue is relevant only when SRIOV is enabled and SM supports
      send only full member.
      
      This fix separates scope bits and join states bits a nibble each.
      
      Fixes: b9c5d6a6 ('IB/mlx4: Add multicast group (MCG) paravirtualization for SR-IOV')
      Signed-off-by: NAlex Vesker <valex@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      e5ac40cd
  5. 03 9月, 2016 2 次提交
  6. 23 8月, 2016 2 次提交
  7. 04 8月, 2016 2 次提交
    • M
      IB/mlx4: Add diagnostic hardware counters · 3f85f2aa
      Mark Bloch 提交于
      Expose IB diagnostic hardware counters.
      The counters count IB events and are applicable for IB and RoCE.
      
      The counters can be divided into two groups, per device and per port.
      Device counters are always exposed.
      Port counters are exposed only if the firmware supports per port counters.
      
      rq_num_dup and sq_num_to are only exposed if we have firmware support
      for them, if we do, we expose them per device and per port.
      rq_num_udsdprd and num_cqovf are device only counters.
      
      rq - denotes responder.
      sq - denotes requester.
      
      |-----------------------|---------------------------------------|
      |	Name		|	Description			|
      |-----------------------|---------------------------------------|
      |rq_num_lle		| Number of local length errors		|
      |-----------------------|---------------------------------------|
      |sq_num_lle		| number of local length errors		|
      |-----------------------|---------------------------------------|
      |rq_num_lqpoe		| Number of local QP operation errors	|
      |-----------------------|---------------------------------------|
      |sq_num_lqpoe		| Number of local QP operation errors	|
      |-----------------------|---------------------------------------|
      |rq_num_lpe		| Number of local protection errors	|
      |-----------------------|---------------------------------------|
      |sq_num_lpe		| Number of local protection errors	|
      |-----------------------|---------------------------------------|
      |rq_num_wrfe		| Number of CQEs with error		|
      |-----------------------|---------------------------------------|
      |sq_num_wrfe		| Number of CQEs with error		|
      |-----------------------|---------------------------------------|
      |sq_num_mwbe		| Number of Memory Window bind errors	|
      |-----------------------|---------------------------------------|
      |sq_num_bre		| Number of bad response errors		|
      |-----------------------|---------------------------------------|
      |sq_num_rire		| Number of Remote Invalid request	|
      |			| errors				|
      |-----------------------|---------------------------------------|
      |rq_num_rire		| Number of Remote Invalid request	|
      |			| errors				|
      |-----------------------|---------------------------------------|
      |sq_num_rae		| Number of remote access errors	|
      |-----------------------|---------------------------------------|
      |rq_num_rae		| Number of remote access errors	|
      |-----------------------|---------------------------------------|
      |sq_num_roe		| Number of remote operation errors	|
      |-----------------------|---------------------------------------|
      |sq_num_tree		| Number of transport retries exceeded	|
      |			| errors				|
      |-----------------------|---------------------------------------|
      |sq_num_rree		| Number of RNR NAK retries exceeded	|
      |			| errors				|
      |-----------------------|---------------------------------------|
      |rq_num_rnr		| Number of RNR NAKs sent		|
      |-----------------------|---------------------------------------|
      |sq_num_rnr		| Number of RNR NAKs received		|
      |-----------------------|---------------------------------------|
      |rq_num_oos		| Number of Out of Sequence requests	|
      |			| received				|
      |-----------------------|---------------------------------------|
      |sq_num_oos		| Number of Out of Sequence NAKs	|
      |			| received				|
      |-----------------------|---------------------------------------|
      |rq_num_udsdprd		| Number of UD packets silently		|
      |			| discarded on the Receive Queue due to	|
      |			| lack of receive descriptor		|
      |-----------------------|---------------------------------------|
      |rq_num_dup		| Number of duplicate requests received	|
      |-----------------------|---------------------------------------|
      |sq_num_to		| Number of time out received		|
      |-----------------------|---------------------------------------|
      |num_cqovf		| Number of CQ overflows		|
      |-----------------------|---------------------------------------|
      Signed-off-by: NMark Bloch <markb@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      3f85f2aa
    • R
      IB/mlx4: Don't use GFP_ATOMIC for CQ resize struct · 0c87b672
      Roland Dreier 提交于
      We allocate a small tracking structure as part of mlx4_ib_resize_cq().
      However, we don't need to use GFP_ATOMIC -- immediately after the
      allocation, we call mlx4_cq_resize(), which allocates a command
      mailbox with GFP_KERNEL and then sleeps on a firmware command, so we
      better not be in an atomic context.
      
      This actually has a real impact, because when this GFP_ATOMIC
      allocation fails (and GFP_ATOMIC does fail in practice) then a
      userspace consumer resizing a CQ will get a spurious failure that we
      can easily avoid.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      0c87b672
  8. 20 7月, 2016 1 次提交
  9. 24 6月, 2016 1 次提交
  10. 23 6月, 2016 5 次提交
  11. 18 6月, 2016 1 次提交
  12. 07 6月, 2016 1 次提交
  13. 18 5月, 2016 1 次提交
    • S
      IB/mlx4: Fix unaligned access in send_reply_to_slave · 04ef0f1a
      shamir rabinovitch 提交于
      The problem is that the function 'send_reply_to_slave' gets the
      'req_sa_mad' as a pointer whose address is only aliged to 4 bytes
      but is 8 bytes in size.  This can result in unaligned access faults
      on certain architectures.
      
      Sowmini Varadhan pointed to this reply from Dave Miller that say
      that memcpy should not be used to solve alignment issues:
      https://lkml.org/lkml/2015/10/21/352
      
      Optimization of memcpy to 'ldx' instruction can only happen if the
      compiler knows that the size of the data we are copying is 8 bytes
      and it assumes it is aligned to 8 bytes. If the compiler know the
      type is not aligned to 8 it must not optimize the 8 byte copy.
      Defining the data type as aligned to 4 forces the compiler to treat
      all accesses as though they aren't aligned and avoids the 'ldx'
      optimization.
      
      Full credit for the idea goes to Jason Gunthorpe
      <jgunthorpe@obsidianresearch.com>.
      Signed-off-by: NShamir Rabinovitch <shamir.rabinovitch@oracle.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      04ef0f1a
  14. 14 5月, 2016 4 次提交
  15. 06 5月, 2016 1 次提交
    • H
      net/mlx4: Avoid wrong virtual mappings · 73898db0
      Haggai Abramovsky 提交于
      The dma_alloc_coherent() function returns a virtual address which can
      be used for coherent access to the underlying memory.  On some
      architectures, like arm64, undefined behavior results if this memory is
      also accessed via virtual mappings that are not coherent.  Because of
      their undefined nature, operations like virt_to_page() return garbage
      when passed virtual addresses obtained from dma_alloc_coherent().  Any
      subsequent mappings via vmap() of the garbage page values are unusable
      and result in bad things like bus errors (synchronous aborts in ARM64
      speak).
      
      The mlx4 driver contains code that does the equivalent of:
      vmap(virt_to_page(dma_alloc_coherent)), this results in an OOPs when the
      device is opened.
      
      Prevent Ethernet driver to run this problematic code by forcing it to
      allocate contiguous memory. As for the Infiniband driver, at first we
      are trying to allocate contiguous memory, but in case of failure roll
      back to work with fragmented memory.
      Signed-off-by: NHaggai Abramovsky <hagaya@mellanox.com>
      Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
      Reported-by: NDavid Daney <david.daney@cavium.com>
      Tested-by: NSinan Kaya <okaya@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73898db0
  16. 28 4月, 2016 1 次提交
  17. 04 3月, 2016 1 次提交
    • A
      net: mellanox: add DEVLINK dependencies · 3d1cbe83
      Arnd Bergmann 提交于
      The new NET_DEVLINK infrastructure can be a loadable module, but the drivers
      using it might be built-in, which causes link errors like:
      
      drivers/net/built-in.o: In function `mlx4_load_one':
      :(.text+0x2fbfda): undefined reference to `devlink_port_register'
      :(.text+0x2fc084): undefined reference to `devlink_port_unregister'
      drivers/net/built-in.o: In function `mlxsw_sx_port_remove':
      :(.text+0x33a03a): undefined reference to `devlink_port_type_clear'
      :(.text+0x33a04e): undefined reference to `devlink_port_unregister'
      
      There are multiple ways to avoid this:
      
      a) add 'depends on NET_DEVLINK || !NET_DEVLINK' dependencies
         for each user
      b) use 'select NET_DEVLINK' from each driver that uses it
         and hide the symbol in Kconfig.
      c) make NET_DEVLINK a 'bool' option so we don't have to
         list it as a dependency, and rely on the APIs to be
         stubbed out when it is disabled
      d) use IS_REACHABLE() rather than IS_ENABLED() to check for
         NET_DEVLINK in include/net/devlink.h
      
      This implements a variation of approach a) by adding an
      intermediate symbol that drivers can depend on, and changes
      the three drivers using it.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 09d4d087 ("mlx4: Implement devlink interface")
      Fixes: c4745500 ("mlxsw: Implement devlink interface")
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d1cbe83
  18. 02 3月, 2016 2 次提交