Eric Lee / smarc-fsl-linux-kernel

17 Nov, 2010

1 commit

  • f281233d3   SCSI host lock push-down ... Browse Code »

    Move the mid-layer's ->queuecommand() invocation from being locked
    with the host lock to being unlocked to facilitate speeding up the
    critical path for drivers who don't need this lock taken anyway.

    The patch below presents a simple SCSI host lock push-down as an
    equivalent transformation. No locking or other behavior should change
    with this patch. All existing bugs and locking orders are preserved.

    Additionally, add one parameter to queuecommand,
    struct Scsi_Host *
    and remove one parameter from queuecommand,
    void (*done)(struct scsi_cmnd *)

    Scsi_Host* is a convenient pointer that most host drivers need anyway,
    and 'done' is redundant to struct scsi_cmnd->scsi_done.

    Minimal code disturbance was attempted with this change. Most drivers
    needed only two one-line modifications for their host lock push-down.

    Signed-off-by: Jeff Garzik
    Acked-by: James Bottomley
    Signed-off-by: Linus Torvalds

    Jeff Garzik
     

30 Mar, 2010

1 commit

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

05 Jan, 2010

1 commit

  • 91e6ecada   [SCSI] stex: fix scan of nonexistent lun ... Browse Code »

    During a manual scan, a user can send command to a nonexistent
    lun, precisely at the point of max_lun. Normally it's possible
    (but not required) that the firmware has the knowledge that it
    is an invalid lun. In the particular case when max_lun is 256,
    however, the nonexistent lun 256 will be confused with lun 0,
    because the lun member in a request message is only u8, and 256
    will become 0. So we need to fix the problem, at least, at the
    driver level.

    Signed-off-by: Ed Lin
    Signed-off-by: James Bottomley

    Ed Lin
     

30 Oct, 2009

3 commits

05 Sep, 2009

1 commit

  • 69cb48750   [SCSI] stex: Add reset code for st_yel (v2) ... Browse Code »

    Add reset related code for st_yel.
    1. Set the SS_H2I_INT_RESET bit.
    2. Wait for the SS_MU_OPERATIONAL flag. This is also part of
    normal handshake process so move it to handshake routine.
    3. Continue handshake with the firmware.

    Signed-off-by: Ed Lin
    Signed-off-by: James Bottomley

    Ed Lin
     

07 Apr, 2009

2 commits

03 Apr, 2009

5 commits

13 Mar, 2009

5 commits

30 Dec, 2008

1 commit

02 Dec, 2008

1 commit

27 Jul, 2008

1 commit

08 Apr, 2008

2 commits

23 Feb, 2008

2 commits

  • c9872fe1a   [SCSI] stex: stex_internal_copy should be called with sg_count in struct st_ccb ... Browse Code »

    stex_internal_copy copies an in-kernel buffer to a sg list by using
    scsi_kmap_atomic_sg. Some functions calls stex_internal_copy with
    sg_count in struct st_ccb, which is the value that dma_map_sg
    returned. However it might be shorter than the actual number of sg
    entries (if the IOMMU merged the sg entries).

    scsi_kmap_atomic_sg doesn't see sg->dma_length so stex_internal_copy
    should be called with the actual number of sg entries
    (i.e. scsi_sg_count), because if the sg entries were merged,
    stex_direct_copy wrongly think that the data length in the sg list is
    shorter than the actual length.

    Signed-off-by: FUJITA Tomonori
    Acked-by: Ed Lin
    Signed-off-by: James Bottomley

    FUJITA Tomonori
     
  • 26106e3ca   [SCSI] stex: stex_direct_copy shouldn't call dma_map_sg ... Browse Code »

    stex_direct_copy copies an in-kernel buffer to a sg list in order to
    spoof some SCSI commands. stex_direct_copy calls dma_map_sg and then
    stex_internal_copy with the value that dma_map_sg returned. It calls
    scsi_kmap_atomic_sg to copy data.

    scsi_kmap_atomic_sg doesn't see sg->dma_length so if dma_map_sg merges
    sg entries, stex_internal_copy gets the smaller number of sg entries
    than the acutual number, which means it wrongly think that the data
    length in the sg list is shorter than the actual length.

    stex_direct_copy shouldn't call dma_map_sg and it doesn't need since
    this code path doesn't involve dma transfers. This patch removes
    stex_direct_copy and simply calls stex_internal_copy with the actual
    number of sg entries.

    Signed-off-by: FUJITA Tomonori
    Acked-by: Ed Lin
    Signed-off-by: James Bottomley

    FUJITA Tomonori
     

31 Jan, 2008

1 commit

  • d3f46f39b   [SCSI] remove use_sg_chaining ... Browse Code »

    With the sg table code, every SCSI driver is now either chain capable
    or broken (or has sg_tablesize set so chaining is never activated), so
    there's no need to have a check in the host template.

    Also tidy up the code by moving the scatterlist size defines into the
    SCSI includes and permit the last entry of the scatterlist pools not
    to be a power of two.
    Signed-off-by: James Bottomley

    James Bottomley
     

16 Oct, 2007

1 commit

15 Jul, 2007

1 commit

31 May, 2007

1 commit

30 May, 2007

1 commit

17 May, 2007

4 commits

  • c25da0afa   [SCSI] stex: minor cleanup and version update ... Browse Code »

    Add debug information into abort and host_reset routine.
    Change ioremap to ioremap_nocache.
    Version updated to 3.6.0000.1.

    Signed-off-by: Ed Lin
    Signed-off-by: James Bottomley

    Ed Lin
     
  • d116a7bc6   [SCSI] stex: fix reset recovery for console device ... Browse Code »

    After reset completed, the scsi error handler sends out TEST_UNIT_READY
    to the device. For 'normal' devices the command will be handled by firmware.
    However, because the RAID console only interfaces to scsi mid layer, the
    firmware will not process the command for it. This will make the console to
    be offlined right after reset. Add the handling in driver to fix this problem.

    Signed-off-by: Ed Lin
    Signed-off-by: James Bottomley

    Ed Lin
     
  • 69f4a5139   [SCSI] stex: extend hard reset wait time ... Browse Code »

    During hard bus reset of st_shasta controllers, 1 ms is not enough for
    16-port controllers, although it's good for 8-port controllers. Extend the
    wait time to 100 ms to allow bus resets finish successfully.

    Signed-off-by: Ed Lin
    Signed-off-by: James Bottomley

    Ed Lin
     
  • e0b2e597d   [SCSI] stex: fix id mapping issue ... Browse Code »

    The correct internal mapping of stex controllers should be:
    id:0~15, lun:0~7 (st_shasta)
    id:0, lun:0~127 (st_yosemite)
    id:0~127, lun:0 (st_vsc and st_vsc1)

    This patch reports the internal mapping to scsi mid layer, eliminating
    the translation between scsi mid layer and firmware. To achieve this
    goal, we also need to:
    -- fail the REPORT_LUNS command for st_shasta because the
    firmware is known to not report all actual luns
    -- add an entry in scsi_devindo.c to force sequential lun scan
    (for st_shasta controllers)
    -- fail the REPORT_LUNS command for console device
    -- remove special handling of REPORT_LUNS command for
    st_yosemite, as there is no translation mapping now

    Signed-off-by: Ed Lin
    Signed-off-by: James Bottomley

    Ed Lin
     

15 Feb, 2007

1 commit

  • cd354f1ae   [PATCH] remove many unneeded #includes of sched.h ... Browse Code »

    After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

06 Dec, 2006

4 commits