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).

into samba.org:/stuff/paulus/kernel/for-linus-ppc

Recently there has been a rash of Unexpected IO APIC reports on the
linux-smp mailing list.  Most of the most recent ones are due to some
newer Intel chipsets (865, 875).

The IO APIC Version register doesn't indicate the differences in these
IO APICs.

I have an patch that addresses these chipsets.  It has been tested by a
few people with good results and has been blessed by Maciej Rozycki.

Other than conditionally decoding IO APIC registers 2 and 3, we could
alternately ignore them since Linux doesn't use the values for anything
other than printing them.

This patch ignores IO APIC register 2 if it's the same value as IO APIC
register 1.  It also reads IO APIC register 3 if the IO APIC version is
>= 0x20, but some chipsets don't support this register, so it is also
ignored if its value if the same as IO APIC register 1 or 2.

Another possible(?) alternative is to read the PID/VID of the device to
determine which registers it supports.  However, PCI devices have not
been scanned at this point in init, so it would require scanning PCI
config space directly and I don't yet see the point of doing that.

Oh, and the UNEXPECTED_IO_APIC() function doesn't print anything in
2.5.current and I didn't change that.

This does the following:

 - IV value is current 512-byte sector relative to start of loop
   container file.  This is what all cryptoloop people have done, if I
   am not mistaken.  Andi or others - if you can demonstrate the need
   for a more flexible setup an additional ioctl field may be needed.  I
   hope we can do without.

 - made some things static

 - made lo_offset a loff_t

 - added lo_sizelimit

   If one wanted a (crypto)loop somewhere inside a container file, the
   old code allowed a starting offset, but no size, so that the
   cryptoloop always extended to the end of the container file.  This
   field allows one to select an arbitrary interval.  Note that this
   changes struct loop_info64.

 - improve error handling of loop_init()

 - removed the unused typedef transfer_proc_t.

 - added a define for LO_CRYPT_CRYPTOAPI

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

The semaphore in pnp_init_resource_table is not needed and, in some
cases, can cause resource management lockups.  This patch removes the
improperly placed semaphore.

In the last release, this api was accidently changed and therefore 
affected some drivers.  This patch corrects the issue by renaming
the api back to pnp_init_resource_table.

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

into kroah.com:/home/greg/linux/BK/gregkh-2.5