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

This is being printed when it shouldn't, but there really isn't an
easy way to fix it.  This closes bug #223.

Making ready for the pre-2.6.x series ...

Add a section about quota-tools in the Changes and version docs.

This makes initramfs use ".incbin" to include a binary blob into the
object file, instead of using LDFLAGS_BLOB, which isn't supported on all
architectures.

This will require reasonably modern binutils, but is portable.

This is the last thing that keeps the standard tree from building
directly for ia64.

Update ColdFire interrupt setup code to return irqreturn_t from
interrupt handlers.

Fix arg passing of interrupt handler to return irqreturn_t in
ColdFire PIT timer initialization..

Fix return type of m68knommu timer interrupt handler to be irqreturn_t.

Reflect Intel manual bugfix, by Philippe Elie

Critical fix to the IO-APIC timer support. By Zwane Mwaikambo.

oprofile_arch_exit() can be called from an __init routine now. Remove the remaining
incorrect __exit markers.

into home.osdl.org:/home/torvalds/v2.5/linux

This brings the chris architecture up to date with 2.5.

The patch is huge because files have been moved to prepare
for future subarchitechtures.

into home.osdl.org:/home/torvalds/v2.5/linux

into shaggy.austin.ibm.com:/shaggy/bk/jfs-2.5

odd-ball IDE controllers without a control register.

(Apparently Amiga X-Surf and Amiga Gayle with IDE doubler)

Also, clean up the code a bit while I'm at it.

into kernel.bkbits.net:/home/davem/net-2.5

These changes to unusual_devs.h can be applied to both 2.5 and 2.4.  They
reflect reports from users in response to the new kernel log messages
about unneeded entries in the file.

into nuts.ninka.net:/home/davem/src/BK/net-2.5

This patch fixes a refcnt leak when the policy changes on us in
xfrm_lookup.

Martin Diehl pointed out that the network layer treats
a tx drop notification in special ways, so "usbnet"
shouldn't be using them.  This fixes that problem,
which could potentially explain some infrequent oopsing
seen in the network layer.  (With memory so tight that
an URB can't be gotten.)

Please merge.

This fixes a problem that's been around for some time:
usbcore will sometimes use un-initialized memory as if
it holds a valid language code.

This fixes a minor error in usb-skeleton's disconnect() routine: if the
interface's private data is NULL, the current code exits without releasing
the disconnect_sem semaphore.

I removed the test entirely because I can't think of any situation where
that private data actually would be NULL, other than a pretty badly
malfunctioning system.  Why test for something that should never happen?
And if it does happen, we shouldn't want the disconnect routine to fail
silently -- we should want to see a nice big segfault (when the NULL
pointer is dereferenced) so that we can find and fix the underlying error.

Is there any sort of convention (a la Documentation/CodingStyle) about
whether this approach should be used in general?  There are _lots_ of
places in the kernel where unnecessary checks for NULL pointers are made.

This patch makes the Datafab and the Freecom driver both use the I/O safe
buffer us->iobuf instead of local stack or local allocations.

This patch makes the 2.5 initializers use the DMA-safe us->iobuf instead of
local stack or local dynamic allocation.

A couple of patches for the ftdi_sio driver on 2.5.73

"2.5.73-ftdi_sio-bigupdate.patch" - this is a big, ugly patch to
bring the ftdi_sio driver in line with what recently submitted for
inclusion in the 2.4.x kernel
(v2.4/testing/cset/cset-abbotti@mev.co.uk|ChangeSet|20030627190202|35624.txt),
but with necessary changes for 2.5.x.  I've bumped the driver's
version number to 1.4.0 to distinguish it from that submitted for
the 2.4.x kernel.

"2.5.73-ftdi_sio-dynamicwrite.patch" - this adds to the above patch
to replace the pool of urbs used for writes with dynamically
allocated urbs and transfer buffers.  I've tested this on the
FT8U232AM and FT232BM and I think I've catered for the older "SIO"
device, but I don't have a device to test that.  Also, it is not
safe to unload the driver module while write urbs are in flight
(same as for the Visor driver).