Eric Lee / smarc-fsl-linux-kernel

30 Jun, 2011

1 commit

25 Jan, 2011

1 commit

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 Dec, 2009

2 commits

21 Jun, 2009

1 commit

  • 598fa4b77   enhance device info matching for multiple tables ... Browse Code »

    The current scsi_devinfo.c matching routines use a single table for
    the global blacklist. However, we're developing a need to blacklist
    from specific transports too (notably some tape drives using SPI which
    don't respond well to high speed protocols). Instead of developing
    separate blacklist matching for each transport class needing it,
    enhance the current list matching to permit multiple lists.

    Signed-off-by: James Bottomley

    James Bottomley
     

15 Jun, 2009

1 commit

31 Mar, 2009

1 commit

  • 99b762338   proc 2/2: remove struct proc_dir_entry::owner ... Browse Code »

    Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
    as correctly noted at bug #12454. Someone can lookup entry with NULL
    ->owner, thus not pinning enything, and release it later resulting
    in module refcount underflow.

    We can keep ->owner and supply it at registration time like ->proc_fops
    and ->data.

    But this leaves ->owner as easy-manipulative field (just one C assignment)
    and somebody will forget to unpin previous/pin current module when
    switching ->owner. ->proc_fops is declared as "const" which should give
    some thoughts.

    ->read_proc/->write_proc were just fixed to not require ->owner for
    protection.

    rmmod'ed directories will be empty and return "." and ".." -- no harm.
    And directories with tricky enough readdir and lookup shouldn't be modular.
    We definitely don't want such modular code.

    Removing ->owner will also make PDE smaller.

    So, let's nuke it.

    Kudos to Jeff Layton for reminding about this, let's say, oversight.

    http://bugzilla.kernel.org/show_bug.cgi?id=12454

    Signed-off-by: Alexey Dobriyan

    Alexey Dobriyan
     

14 Jan, 2009

1 commit

  • debf47779   [SCSI] Add SUN Universal Xport to no attach blacklist ... Browse Code »

    I was using a Sun ST2510 device (iSCSI) and a special "block device"
    appeared which is used by SUN Common Array Manager in-band management.

    However it also appeared as a block device and caused some IO error:

    [ 716.868000] scsi 15:0:0:31: Direct-Access SUN Universal Xport 0735 PQ: 0 ANSI: 5
    [ 716.868000] qla4xxx 0000:04:01.1: scsi(15:0:0:31): Enabled tagged queuing, queue depth 32.
    [ 716.868000] sd 15:0:0:31: [sdf] 40960 512-byte hardware sectors (21 MB)
    [ 716.868000] sd 15:0:0:31: [sdf] Write Protect is off
    [ 716.868000] sd 15:0:0:31: [sdf] Mode Sense: 77 00 10 08
    [ 716.868000] sd 15:0:0:31: [sdf] Write cache: disabled, read cache: enabled, supports DPO and FUA
    [ 716.868000] sd 15:0:0:31: [sdf] 40960 512-byte hardware sectors (21 MB)
    [ 716.868000] sd 15:0:0:31: [sdf] Write Protect is off
    [ 716.868000] sd 15:0:0:31: [sdf] Mode Sense: 77 00 10 08
    [ 716.872000] sd 15:0:0:31: [sdf] Write cache: disabled, read cache: enabled, supports DPO and FUA
    [ 716.872000] sdf: unknown partition table
    [ 716.932000] sd 15:0:0:31: [sdf] Attached SCSI disk
    [ 716.932000] sd 15:0:0:31: Attached scsi generic sg6 type 0
    [ 717.412000] end_request: I/O error, dev sdf, sector 40
    [ 717.412000] Buffer I/O error on device sdf, logical block 5
    [ 717.412000] Buffer I/O error on device sdf, logical block 6
    [ 717.412000] Buffer I/O error on device sdf, logical block 7
    [ 717.412000] Buffer I/O error on device sdf, logical block 8
    [ 717.412000] Buffer I/O error on device sdf, logical block 9
    [ 717.412000] Buffer I/O error on device sdf, logical block 10
    [ 717.412000] Buffer I/O error on device sdf, logical block 11
    [ 717.412000] Buffer I/O error on device sdf, logical block 12
    [ 717.412000] Buffer I/O error on device sdf, logical block 13
    [ 717.412000] Buffer I/O error on device sdf, logical block 14

    After some googling it appeared that similar issue has been solved for
    SGI/IBM devices in 4869040512082b761de2d7c35975d01044f8bfea, so here is
    the patch for SUN, please apply.

    Signed-off-by: James Bottomley

    ILLES, Marton
     

27 Jul, 2008

1 commit

29 Apr, 2008

1 commit

  • 352ced8e5   proc: switch /proc/scsi/device_info to seq_file interface ... Browse Code »

    Note 1: 0644 should be used, but root bypasses permissions, so writing
    to /proc/scsi/device_info still works.
    Note 2: looks like scsi_dev_info_list is unprotected
    Note 3: probably make proc whine about "unwriteable but with ->write hook"
    entries. Probably.

    Signed-off-by: Alexey Dobriyan
    Cc: James Bottomley
    Cc: Mike Christie
    Cc: Matthew Wilcox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

12 Jan, 2008

2 commits

13 Oct, 2007

1 commit

28 Jul, 2007

1 commit

15 Jul, 2007

1 commit

17 May, 2007

1 commit

  • 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
     

02 Oct, 2006

4 commits

26 Jun, 2006

1 commit

  • 9ba0883cf   [SCSI] HP XP devinfo update ... Browse Code »

    According to Anthony Cheung all HP XP arrays with "OPEN-"
    types support REPORT_LUN. So there is no reason why we
    shouldn't use it.

    Signed-off-by: Anthony Cheung
    Signed-off-by: Hannes Reinecke
    Signed-off-by: James Bottomley

    Hannes Reinecke
     

11 Jun, 2006

1 commit

20 May, 2006

1 commit

  • c3d833685   [SCSI] Blacklist entry for HP dat changer ... Browse Code »

    after upgrading our SUN E250 from 2.4 to 2.6 I'm seeing following error
    when the HP DDS4 DAT changer gets probed:

    scsi: host 1 channel 0 id 5 lun16777216 has a LUN larger than allowed by
    the host adapter

    The device is connected to a symbios 875 host. I've talked to Willy
    about the problem, and he asked me to try to blacklist the device
    for reportlun. I did that with the patch below and it solved the
    problem. It now gets properly detected:

    target1:0:5: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 16)
    Vendor: HP Model: C5713A Rev: H307
    Type: Sequential-Access ANSI SCSI revision: 03
    target1:0:5: Beginning Domain Validation
    target1:0:5: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16)
    target1:0:5: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 16)
    target1:0:5: Domain Validation skipping write tests
    target1:0:5: Ending Domain Validation
    Vendor: HP Model: C5713A Rev: H307
    Type: Medium Changer ANSI SCSI revision: 03

    Signed-off-by: tsbogend@alpha.franken.de
    Signed-off-by: James Bottomley

    Thomas Bogendoerfer
     

28 Apr, 2006

1 commit

  • f2536cbd1   [SCSI] scsi: Add IBM 2104-DU3 to blist ... Browse Code »

    Some versions of the IBM 2104-DU3 disk enclosure
    have been observed to hang Inquiries to non zero
    LUNs to the SES device. This device only has LUN 0,
    so this patch adds it to the BLIST to prevent scsi
    core from scanning beyond LUN 0.

    Signed-off-by: Brian King
    Signed-off-by: James Bottomley

    Brian King
     

15 Apr, 2006

2 commits

  • 84d891d67   Merge ../scsi-rc-fixes-2.6 ... Browse Code »

    Conflicts:

    include/scsi/scsi_devinfo.h

    Same number for two BLIST flags: BLIST_MAX_512 and BLIST_ATTACH_PQ3

    Signed-off-by: James Bottomley

    James Bottomley
     
  • 13f7e5acc   [SCSI] BLIST_ATTACH_PQ3 flags ... Browse Code »

    Some devices report a peripheral qualifier of 3 for LUN 0; with the original
    code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
    have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
    Also, the device at LUN 0 (which is not connected according to the PQ) is not
    registered with the OS.

    Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
    report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
    most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
    reference for an infamous example.

    This is patch 3/3:
    3. Implement the blacklist flag BLIST_ATTACH_PQ3 that makes the scsi
    scanning code register PQ3 devices and continues scanning; only sg
    will attach thanks to scsi_bus_match().

    Signed-off-by: Kurt Garloff
    Signed-off-by: James Bottomley

    Kurt Garloff
     

13 Apr, 2006

1 commit

  • 4d7db04a7   [SCSI] add SCSI_UNKNOWN and LUN transfer limit restrictions ... Browse Code »

    Original From: Ingo Flaschberger

    To support the RA4100 array from Compaq.

    This patch now correctly handles SCSI_UNKNOWN types with regard to
    BLIST_REPORTLUNS2 (allow it) and cdb[1] LUN inclusion (don't).

    It also allows a BLIST_MAX_512 flag to restrict the maximum transfer
    length to 512 blocks (apparently this is an RA4100 problem).

    Signed-off-by: James Bottomley

    James Bottomley
     

03 Mar, 2006

1 commit

14 Dec, 2005

1 commit

18 Oct, 2005

1 commit

13 Sep, 2005

1 commit

07 Sep, 2005

1 commit

  • 486904051   [SCSI] Universal Xport no attach blacklist ... Browse Code »

    On Fri, Dec 13, 2002 at 12:24:39AM +1100, Anton Blanchard wrote:

    > We tested 2.5.51 on a ppc64 box, qlogic 2312 and a fastt700 array. I
    > had CONFIG_SCSI_REPORT_LUNS and unfortunately it thought the management
    > LUN was a disk:
    >
    > Vendor: IBM Model: Universal Xport Rev: 0520
    > Type: Direct-Access ANSI SCSI revision: 03
    >
    > ...
    >
    > SCSI device sdaj: drive cache: write through
    > SCSI device sdaj: 40960 512-byte hdwr sectors (21 MB)
    > sdaj: unknown partition table
    > Attached scsi disk sdaj at scsi2, channel 0, id 0, lun 31
    >
    > ...
    >
    > end_request: I/O error, dev sdaj, sector 0

    Three years later...

    It looks like SGI use the same FC vendor and they already have a
    workaround for this issue. The following patch adds the IBM version of
    it.

    Signed-off-by: Anton Blanchard
    Signed-off-by: James Bottomley

    Anton Blanchard
     

13 Aug, 2005

1 commit

  • 507caac75   [SCSI] Make the HSG80 a REPORTLUN2 device ... Browse Code »

    From: Steve Wilcox

    In order to properly report LUN's > 7, the DEC HSG80 definition in
    scsi_devinfo.c needs to include BLIST_REPORTLUN2 rather than
    BLIST_SPARSELUN. I've tested this change with several HSG firmware
    revisions and with both Emulex and Qlogic HBA's.

    Signed-off-by: James Bottomley

    James Bottomley
     

09 Aug, 2005

1 commit

  • 0d7323c86   [SCSI] blacklist addition. ... Browse Code »

    When run on a kernel that scans all LUNs, a certain crappy
    scsi scanner reports the same LUN over and over..
    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155457

    Aparently they were so shamed by this, they chose to remain
    anonymous. Though it seems the blacklist code handles
    anonymous vendors just fine.

    Signed-off-by: Dave Jones
    Signed-off-by: James Bottomley

    Dave Jones
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds