13 Oct, 2007

1 commit

  • The pid field is a duplicate of the serial_number field and has been
    scheduled for removal for a long time. A few drivers were still using
    it, so just change them to use serial_number instead.

    Signed-off-by: Matthew Wilcox
    Signed-off-by: James Bottomley

    Matthew Wilcox
     

19 Jul, 2007

1 commit

  • - #include for getting the prototypes of {dis,en}able_irq()

    - make the needlessly global wd33c93_setup() static

    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: James Bottomley

    Adrian Bunk
     

16 Feb, 2007

1 commit

  • Attached are patches, which help to utilize more of the WD33C93B SCSI
    controller's capabilities.

    1) Added/changed all the necessary code to enable Burst Mode DMA. Only
    Single Byte DMA was used before.

    2) Added/changed all the necessary code to enable Fast-10 SCSI transfers.

    3) The original driver inadvertently used a transfer period of 1000-800ns
    (the lowest possible transfer rate) for asynchronous data transfers,
    instead of the (configurable) default period intended for this purpose,
    if the target responded to a SDTR not with a Reject-message, but with
    a zero-SDTR. This issue was fixed.
    Moreover, in case of a Reject the driver used the default-period's
    initialization-value instead of its (maybe smaller) current value. The
    missing assignment was added.

    4) The driver's commandline- and proc-file-interface was augmented to
    handle the new options properly.

    The WD33C93 manual, found at
    http://www.datasheet.in/datasheet-html/W/D/3/WD33C93B_WesternDigital.pdf.html,
    was very helpful.

    Signed-off-by: peter fuerst
    Signed-off-by: James Bottomley

    peter fuerst
     

15 Feb, 2007

1 commit

  • 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
     

14 Jul, 2006

1 commit


01 Jul, 2006

1 commit


23 Jun, 2006

1 commit


10 Jun, 2006

1 commit


12 Mar, 2006

1 commit


13 Jan, 2006

1 commit


09 Nov, 2005

1 commit

  • This patch removes almost all inclusions of linux/version.h. The 3
    #defines are unused in most of the touched files.

    A few drivers use the simple KERNEL_VERSION(a,b,c) macro, which is
    unfortunatly in linux/version.h.

    There are also lots of #ifdef for long obsolete kernels, this was not
    touched. In a few places, the linux/version.h include was move to where
    the LINUX_VERSION_CODE was used.

    quilt vi `find * -type f -name "*.[ch]"|xargs grep -El '(UTS_RELEASE|LINUX_VERSION_CODE|KERNEL_VERSION|linux/version.h)'|grep -Ev '(/(boot|coda|drm)/|~$)'`

    search pattern:
    /UTS_RELEASE\|LINUX_VERSION_CODE\|KERNEL_VERSION\|linux\/\(utsname\|version\).h

    Signed-off-by: Olaf Hering
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Olaf Hering
     

17 Apr, 2005

1 commit

  • 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