1. 31 8月, 2015 1 次提交
  2. 13 6月, 2015 4 次提交
    • I
      IB/mad: Add final OPA MAD processing · 8e4349d1
      Ira Weiny 提交于
      For devices which support OPA MADs
      
         1) Use previously defined SMP support functions.
      
         2) Pass correct base version to ib_create_send_mad when processing OPA MADs.
      
         3) Process out_mad_key_index returned by agents for a response.  This is
            necessary because OPA SMP packets must carry a valid pkey.
      
         4) Carry the correct segment size (OPA vs IBTA) of RMPP messages within
            ib_mad_recv_wc.
      
         5) Handle variable length OPA MADs by:
      
              * Adjusting the 'fake' WC for locally routed SMP's to represent the
                proper incoming byte_len
              * out_mad_size is used from the local HCA agents
                      1) when sending agent responses on the wire
                      2) when passing responses through the local_completions
      		   function
      
      	NOTE: wc.byte_len includes the GRH length and therefore is different
      	      from the in_mad_size specified to the local HCA agents.
      	      out_mad_size should _not_ include the GRH length as it is added
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      8e4349d1
    • I
      IB/mad: Add partial Intel OPA MAD support · f28990bc
      Ira Weiny 提交于
      Add OPA SMP processing functionality.
      
      Define the new OPA SMP format, create support functions for this format using
      the previously defined helper functions as appropriate.
      
      These functions are defined in this patch and used in the final OPA MAD support
      patch.
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      f28990bc
    • I
      IB/mad: Add partial Intel OPA MAD support · 548ead17
      Ira Weiny 提交于
      This patch is the first of 3 which adds processing of OPA MADs
      
      1) Add Intel Omni-Path Architecture defines
      2) Increase max management version to accommodate OPA
      3) update ib_create_send_mad
      	If the device supports OPA MADs and the MAD being sent is the OPA base
      	version alter the MAD size and sg lengths as appropriate
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      548ead17
    • I
      IB/mad: Convert allocations from kmem_cache to kzalloc · c9082e51
      Ira Weiny 提交于
      This patch implements allocating alternate receive MAD buffers within the MAD
      stack.  Support for OPA to send/recv variable sized MADs is implemented later.
      
          1) Convert MAD allocations from kmem_cache to kzalloc
      
             kzalloc is more flexible to support devices with different sized MADs
             and research and testing showed that the current use of kmem_cache does
             not provide performance benefits over kzalloc.
      
          2) Change struct ib_mad_private to use a flex array for the mad data
          3) Allocate ib_mad_private based on the size specified by devices in
             rdma_max_mad_size.
          4) Carry the allocated size in ib_mad_private to be used when processing
             ib_mad_private objects.
          5) Alter DMA mappings based on the mad_size of ib_mad_private.
          6) Replace the use of sizeof and static defines as appropriate
          7) Add appropriate casts for the MAD data when calling processing
             functions.
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      c9082e51
  3. 21 5月, 2015 1 次提交
  4. 11 8月, 2014 1 次提交
  5. 07 9月, 2009 1 次提交
  6. 15 7月, 2008 1 次提交
  7. 26 1月, 2008 1 次提交
  8. 03 5月, 2007 1 次提交
    • J
      PCI: Cleanup the includes of <linux/pci.h> · 6473d160
      Jean Delvare 提交于
      I noticed that many source files include <linux/pci.h> while they do
      not appear to need it. Here is an attempt to clean it all up.
      
      In order to find all possibly affected files, I searched for all
      files including <linux/pci.h> but without any other occurence of "pci"
      or "PCI". I removed the include statement from all of these, then I
      compiled an allmodconfig kernel on both i386 and x86_64 and fixed the
      false positives manually.
      
      My tests covered 66% of the affected files, so there could be false
      positives remaining. Untested files are:
      
      arch/alpha/kernel/err_common.c
      arch/alpha/kernel/err_ev6.c
      arch/alpha/kernel/err_ev7.c
      arch/ia64/sn/kernel/huberror.c
      arch/ia64/sn/kernel/xpnet.c
      arch/m68knommu/kernel/dma.c
      arch/mips/lib/iomap.c
      arch/powerpc/platforms/pseries/ras.c
      arch/ppc/8260_io/enet.c
      arch/ppc/8260_io/fcc_enet.c
      arch/ppc/8xx_io/enet.c
      arch/ppc/syslib/ppc4xx_sgdma.c
      arch/sh64/mach-cayman/iomap.c
      arch/xtensa/kernel/xtensa_ksyms.c
      arch/xtensa/platform-iss/setup.c
      drivers/i2c/busses/i2c-at91.c
      drivers/i2c/busses/i2c-mpc.c
      drivers/media/video/saa711x.c
      drivers/misc/hdpuftrs/hdpu_cpustate.c
      drivers/misc/hdpuftrs/hdpu_nexus.c
      drivers/net/au1000_eth.c
      drivers/net/fec_8xx/fec_main.c
      drivers/net/fec_8xx/fec_mii.c
      drivers/net/fs_enet/fs_enet-main.c
      drivers/net/fs_enet/mac-fcc.c
      drivers/net/fs_enet/mac-fec.c
      drivers/net/fs_enet/mac-scc.c
      drivers/net/fs_enet/mii-bitbang.c
      drivers/net/fs_enet/mii-fec.c
      drivers/net/ibm_emac/ibm_emac_core.c
      drivers/net/lasi_82596.c
      drivers/parisc/hppb.c
      drivers/sbus/sbus.c
      drivers/video/g364fb.c
      drivers/video/platinumfb.c
      drivers/video/stifb.c
      drivers/video/valkyriefb.c
      include/asm-arm/arch-ixp4xx/dma.h
      sound/oss/au1550_ac97.c
      
      I would welcome test reports for these files. I am fine with removing
      the untested files from the patch if the general opinion is that these
      changes aren't safe. The tested part would still be nice to have.
      
      Note that this patch depends on another header fixup patch I submitted
      to LKML yesterday:
        [PATCH] scatterlist.h needs types.h
        http://lkml.org/lkml/2007/3/01/141Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6473d160
  9. 13 12月, 2006 1 次提交
  10. 22 11月, 2006 1 次提交
  11. 24 9月, 2006 1 次提交
  12. 23 9月, 2006 1 次提交
  13. 18 6月, 2006 1 次提交
  14. 13 5月, 2006 1 次提交
    • S
      IB: refcount race fixes · 1b52fa98
      Sean Hefty 提交于
      Fix race condition during destruction calls to avoid possibility of
      accessing object after it has been freed.  Instead of waking up a wait
      queue directly, which is susceptible to a race where the object is
      freed between the reference count going to 0 and the wake_up(), use a
      completion to wait in the function doing the freeing.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      1b52fa98
  15. 30 3月, 2006 1 次提交
  16. 21 3月, 2006 1 次提交
    • J
      IB/umad: Add support for large RMPP transfers · f36e1793
      Jack Morgenstein 提交于
      Add support for sending and receiving large RMPP transfers.  The old
      code supports transfers only as large as a single contiguous kernel
      memory allocation.  This patch uses linked list of memory buffers when
      sending and receiving data to avoid needing contiguous pages for
      larger transfers.
      
        Receive side: copy the arriving MADs in chunks instead of coalescing
        to one large buffer in kernel space.
      
        Send side: split a multipacket MAD buffer to a list of segments,
        (multipacket_list) and send these using a gather list of size 2.
        Also, save pointer to last sent segment, and retrieve requested
        segments by walking list starting at last sent segment. Finally,
        save pointer to last-acked segment.  When retrying, retrieve
        segments for resending relative to this pointer.  When updating last
        ack, start at this pointer.
      Signed-off-by: NJack Morgenstein <jackm@mellanox.co.il>
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      f36e1793
  17. 26 10月, 2005 1 次提交
    • S
      [IB] Fix MAD layer DMA mappings to avoid touching data buffer once mapped · 34816ad9
      Sean Hefty 提交于
      The MAD layer was violating the DMA API by touching data buffers used
      for sends after the DMA mapping was done.  This causes problems on
      non-cache-coherent architectures, because the device doing DMA won't
      see updates to the payload buffers that exist only in the CPU cache.
      
      Fix this by having all MAD consumers use ib_create_send_mad() to
      allocate their send buffers, and moving the DMA mapping into the MAD
      layer so it can be done just before calling send (and after any
      modifications of the send buffer by the MAD layer).
      
      Tested on a non-cache-coherent PowerPC 440SPe system.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      34816ad9
  18. 27 8月, 2005 2 次提交
  19. 28 7月, 2005 5 次提交
  20. 17 4月, 2005 2 次提交