The SCSI_IOCTL_SEND_COMMAND ioctl does not work in 2.5.73-bk7. The
following patch (possibly mangled by my mail client) does fix the problem
(introduced in 2.5.73):

Doing some debugging after the SDET failure, I found that
if we reject a command at zero depth, we can get into the
infinite loop where we refuse a command to a LUN because it
is starved, but there's no returning command to run the SCSI
queues and fix the starvation.

The solution is to accept the command and remove the LUN from
the starved list.

This adds support for the Q720 MCA SCSI driver.  It's only really
useful on the voyager platform.  The driver is preliminary and
currently makes no use of the Q720 on-board memory for storing
scripts and ccbs.

- Remove direct configuration of this driver
- Only remaining use is in the parisc zalon driver
- Split the driver up to make it more use to 720 based drivers
- Update zalon to new module/SCSI methods

it should use scsi_host_alloc/scsi_host_put now.

The sym2 driver has a check for a very broken bios where it seems
devices appear twice. This test is broken on a machine with PCI domains
since busnumber:devfn is not a unique identifier.

When we move to the scsi hotplug interface all this code will go away
but in the short term we need the following fix.

aacraid was using the old and erroneously unshifted status return
codes.  Switch it to use the new SAM_STAT_ codes that don't need
shifting.

Some HBA drivers don't set this until their ->detect routines,
so don't check for it until scsi_add_host

and also remove no longer used .command entry

The consolidation of the SCSI data direction flags eliminate the
need for it.

With the simplification of the DMA direction/SCSI data direction
linux/pci.h is no longer pulled in by scsi.h

Make the *_data_direction flags of type enum dma_data_direction from
the generic dma mapping API.  The SCSI_DATA_* defines are kept for
compatiblity and map to the dma mapping API values now.
scsi_to_pci_dma_dir and scsi_to_sbus_dma_dir are kept as stubs -
we define them to nothing as both the PCI and SBUS constants have
the same values as the generic dma mapping ones.  Unfortunately
we can't check anymore whether someone messes this up as the values
are enumes now and not cpp defines.

The included patch updates the old aha1740 driver to some of the 2.5
APIs :

- Generic DMA API
- EISA probing API
- SCSI hotplug API

It's been heavily tested on x86 (UP and SMP) as well as alpha (UP) for
the past two months.

This patch makes sym53c8xx_2 silently ignore the Ignore Wide Residue
message on autosense commands rather than rejecting it.  This makes
the SCSI communications cleaner for targets that return an odd number
of sense bytes.

include/scsi/scsi_driver.h contains æverything related to upper
level drivers.  Unlike the other header moves there's no compatiblity
this time as it's easy to fix up the few users.

The shost_attrs stuff looks fine, expect for two points.

	1. The scsi_sysfs_modify_shost_attribute() and
scsi_sysfs_modify_sdev_attribute() functions appear to be written a bit
carelessly.  Below is a patch that: permits modification of the first
attribute in the list, allocates a new list with entries having the
correct size, copies the correct number of entries from the old list, and
wraps excessively long source lines.

	2. More importantly, the current organization of the code has a
serious problem.  The SCSI core does not modify the host driver when the
reference count for either shost->class_dev or shost->host_gendev drops to
0.  Without knowing that, it is unsafe for the driver ever to deallocate a
private host data structure, since a user process may continue to hold a
reference to an open attribute file indefinitely, even after
scsi_unregister() has returned.

I thought we had an agreement for a long time already that the use of
dma64_addr_t in the sym53c8xx_2 driver was wrong, but it's still
there.

When writing to the rescan attribute, return count as result, otherwise
some user apps might retry the write forever.

And remove the read capability of the attribute.

The patch below postfixes two constants in ips.c with ULL, on 32 bit
archs this constant is too big for an int.

The cast doesn't do the right thing, 0xffffffffffffffff is in C an int
and the cast casts 0xffffffffffffffff interpreted as an int to an u64.

The patch below postfixes a constant in sym53c8xx_2/sym_glue.c with ULL,
on 32 bit archs this constant is too big for an int.

From: Geert Uytterhoeven <geert@linux-m68k.org>

SPC-3 (rev 13) says that 252 bytes in the maximum (and
recommended) length for a REQUEST SENSE reponse.

Linux asks for 254 bytes in scsi_error.c .

That number was not specified in SPC-2 (although the
allocation length field is 1 byte thus limiting it to
255). Seems as though some numbers are being rounded
down to be multiples of 4.

This is to give a proper warning if someone tries to load an
unconverted old-style driver.

From:  Alan Stern <stern@rowland.harvard.edu>

The patch below does the following cleanups on
drivers/scsi/seagate.{c,h}:
- remove two unused functions
- remove a function declaration for a function that is no longer present

I've tested the compilation with 2.5.72-mm2.

The patch below removes an unused function from nsp32.c .

I've tested the compilation with 2.5.72-mm2.

The patch below does the following:
- remove an unused static function
- removes the declaration of a function that is no longer present
- removes a variable declaration that shadows a function parameter

I've tested the compilation with 2.5.72-mm2.

The patch below removes a declaration for a function that is no longer
present.

I've tested the compilation with 2.5.72-mm2.

The patch belowremoves an unused variable from drivers/scsi/fd_mcs.c .

I've tested the compilation with 2.5.72-mm2.

From Douglas Gilbert <dougg@torque.net>

Move the mode_sense request routines to a central location and make
all block device consumers use it.  Also abstract the header as
part of the return to hide the 6/10 differences.

into home.transmeta.com:/home/torvalds/v2.5/linux

This error is handled in the signal delivery code and should never be
returned from a syscall unless a signal is pending.  Grepping seems to
indicate that that is in fact the case (but not for ERESTARTSYS, but
that is another problem).