25 Mar, 2009

1 commit


28 Feb, 2009

1 commit

  • Fix ib_set_rmpp_flags() to use the correct bit mask for RRespTime. In
    the 8-bit field of the RMPP header, the first 5 bits are RRespTime and
    next 3 bits are RMPPFlags. Hence to retain the first 5 bits, the mask
    should be 0xF8 instead of 0xF1.

    ack_recv()-->format_ack() calls ib_set_rmpp_flags() and due to the
    incorrect ANDing with 0xF1, RRespTime got changed incorrectly and RMPP
    Acks sent back always had a RRespTime of 0x1E (30) which caused the
    other end to consider the time outs to be approximately 4297 seconds
    (i.e. in the order of 4*2^30) instead of the usual ~4 seconds (order
    of 4*2^20).

    Signed-off-by: Ramachandra K
    Acked-by: Sean Hefty
    Signed-off-by: Roland Dreier

    Ramachandra K
     

18 Jan, 2009

1 commit

  • The base versions handle constant folding just fine, use them
    directly. The replacements are OK in the include/ files as they are
    not exported to userspace so we don't need the __ prefixed versions.

    This patch does not affect code generation at all.

    Signed-off-by: Harvey Harrison
    Signed-off-by: Roland Dreier

    Harvey Harrison
     

15 Jul, 2008

1 commit


26 Jan, 2008

1 commit

  • To allow ULPs to tune timeout values and capture retry statistics,
    report the number of times that a mad send operation was retried.

    For RMPP mads, report the total number of times that the any portion
    (send window) of the send operation was retried.

    Signed-off-by: Sean Hefty
    Signed-off-by: Roland Dreier

    Sean Hefty
     

04 Aug, 2007

1 commit


11 Jul, 2007

1 commit

  • MADs sent to the SA should use the the default P_Key (0x7fff/0xffff).
    There's no requirement that the default P_Key is stored at index 0 in
    the local P_Key table, so add code to the sa_query module to look up
    the index of the default P_Key when creating an address handle for the
    SA (which is done any time the P_Key table might change), and use this
    index for all SA queries.

    Signed-off-by: Sean Hefty
    Signed-off-by: Roland Dreier

    Sean Hefty
     

03 May, 2007

1 commit

  • I noticed that many source files include 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 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/141

    Signed-off-by: Jean Delvare
    Cc: Badari Pulavarty
    Signed-off-by: Greg Kroah-Hartman

    Jean Delvare
     

25 Jul, 2006

1 commit

  • Validate MADs sent by userspace clients for spec compliance with
    C13-18.1.1 (prevent duplicate requests and responses sent on the
    same port). Without this, RMPP transactions get aborted because
    of duplicate packets.

    This patch is similar to that provided by Jack Morgenstein.

    Signed-off-by: Sean Hefty
    Signed-off-by: Michael S. Tsirkin
    Signed-off-by: Jack Morgenstein
    Signed-off-by: Roland Dreier

    Sean Hefty
     

30 Mar, 2006

1 commit


21 Mar, 2006

1 commit

  • 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: Jack Morgenstein
    Signed-off-by: Sean Hefty
    Signed-off-by: Roland Dreier

    Jack Morgenstein
     

26 Oct, 2005

1 commit

  • 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: Sean Hefty
    Signed-off-by: Roland Dreier

    Sean Hefty
     

09 Oct, 2005

1 commit

  • - added typedef unsigned int __nocast gfp_t;

    - replaced __nocast uses for gfp flags with gfp_t - it gives exactly
    the same warnings as far as sparse is concerned, doesn't change
    generated code (from gcc point of view we replaced unsigned int with
    typedef) and documents what's going on far better.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

22 Sep, 2005

1 commit


10 Sep, 2005

1 commit


27 Aug, 2005

1 commit