The patch is obviously correct and has been floating on lkml for some time.

From Manfred Spraul:
 "My init_irq cleanup introduced a bug: on error, the function must return 1."

Looks like my finger fell off the control key..

Fix some warnings from the new code-patching stuff.

- Fix printk bug in the diagnostic code.

- If an error occurs, print the address of all the offending action
  handlers.  Also the symbol name if CONFIG_KALLSYMS.

The invalidate_buffers in ->release is wrong, get a reference to the
discipline in the beginning of ->open.

This one probably crept in during an ide merge from 2.4..

It looks like no one even tried to use it on 2.5..

Return an error code instead of a devfs_handle_t.  The handle isn't
useful for anything and the !CONFIG_DEVFS_FS stub in fact returned
NULL which made it entirely useless.  Thus only one driver is actually
checking the retval in the current tree..

Now that devfs_handle_t is gone from all structs there is no
reason to include it in headers.

Fix the fallout by including previously implicit headers and fixing
the drivers that didn't include devfs_fs_kernel.h explicitly.

They are obsfucating aliases for SetPageReserved/ClearPageReserved.
And once they're gone we can nuke <linux/wrapper.h>

And uninline end_request - it's calling to many functions to be useful
inline.

They don't have any code in common, so the initrd support can
go into a separate file and not require ramdisk support.

Lots of ifdefs gone and smaller kernel images for initrd users.

not be marked __init.

Noted by Petr Vandrovec

	* we allow tty_driver to cover more than 256 devices
	* pty.c cleaned up - now we only one driver for UNIX98 masters and
only one driver for UNIX98 slaves, so a lot of ugliness can be killed.
	* get_tty_driver() became an analog of get_gendisk() - it does
a lookup by device number and gives (pointer to tty_driver,index).
	* registration/unregistration of tty_driver updated
	* /proc/tty/drivers code updated (now one structure can be responsible
for several lines)

	tty->device switched to dev_t
	There are very few uses of tty->device left by now; most of
them actually want dev_t (process accounting, proc/<pid>/stat, several
ioctls, slip.c logics, etc.) and the rest will go away shortly.

Preparations to cleanup:
	* call of get_tty_driver() moved from init_dev() to its callers
	* instead of kdev_t dev we pass struct tty_struct *driver and int index

	* drivers/char/rio/* supports up to 4 boards, each with up to 128
lines.  It used to share termios for 1st/3rd and 2nd/4th boards,  Fixed.
	* cleanups and kdev_t removals - we pass tty instead of tty->device
in a couple of helper functions and instead of comparisons on major(tty->device)
we check where does tty->driver point to.

	* generic_serial.c typo fix (->driver used instead of correct
->driver_data)
	* tubio cleaned up

	sanitized driver->driver_name initialization and use

	tty->tty_index added; we initialize it with minor(tty->device) -
tty->driver->minor_start.  Majority of remaining tty->device uses had
that form and are switched to use of tty->index.

	new field - tty->tty_name;
	initialized to <driver->name><tty index+driver->base_name>
when we allocate tty_struct.  Drivers code switched to use of that
beast (in debugging printks, mostly).  Large, but trivial.

	Instead of registering "drivers" for /dev/tty, /dev/vc/0, /dev/ptmx
and /dev/console (they are never looked up since tty_open() special-cases
them and they should not be looked up - these devices are remapped on open)
we register corresponding chrdev ranges and devfs nodes directly.
	/proc/tty/drivers code updated to keep the contents unchanged

	/proc/tty/drivers converted to seq_file

	Instead of copying tty_driver into tty_struct we put a reference
in there.  tty->driver turned into a pointer, users updated.  Large, but
trivial

	Christoph's fix for devfs problems with pty.

Chuck Ebbert notes that kernel developers are apparently pirates in the
_original_ meaning of the word, and like to "cannonicalize".

I prepared a patch in case anyone cares enough about this.  I tested on
i386 by building and booting.

Swsusp without swap makes no sense, and leads to compilation
failure.  So make the dependency clear in the config files.

- Workaround possible reset loop trying to get IRM sanity
- Logical Unit DIrectory (LUN) support for sbp2(scsi) devices.
- Fix hostnum allocation.
- Whitespace and formatting sync with 2.4 branch.
- Make pcilynx return IRQ_NONE for no interrupts to handle.

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

The cardbus CIS parsing code does not use the PCMCIA resource
subsystem, so there isn't any point in freeing its memory when
we remove PCMCIA memory resources.  We also free CIS resources
immediately prior to calling cb_free().  We might as well move
the function call into cb_free(), thereby making all references
to cb_release_cis_mem() local to cardbus.c

Several PCMCIA cards I have here do not work correctly over a
suspend/resume cycle; the PCMCIA code believes that the card has
been changed in the slot, and therefore performs a remove/insert
cycle.

This seems to be because the card returns more or less random data
when reading memory space, leading to the CIS cache mismatching
the card data.  This in turn is caused because we try to read CIS
data from both the attribute and memory spaces, and we add the result
to the CIS cache whether or not the returned data was valid.

We therefore convert the CIS cache to use a linked list, and provide
a way to remove cached data from that list.  We also replace the
"s->cis_used=0;" construct with a function "destroy_cis_cache(s)"
which clearly describes what we're doing.

If I compile a recent 2.5.x kernel without CONFIG_ISA defined, I get
an oops in validate_mem().  Stack trace contains 0x6b6b6b6 - a clear
sign that freed memory is being accessed.

It's the second validate_mem() in drivers/pcmcia/rsrc_mgr.c - the one
used when CONFIG_PCMCIA_PROBE is not defined.  It turns out the memory
is freed in do_mem_probe() when it's called from validate_mem().

The solution is to use the same trick as in the first validate_mem().
This problem is quite serious and it's not specific to the plx9052
driver. I see it with yenta_socket as well.

From Christoph Hellwig

There's no need to keep the stubs around.

Patch from Pavel Roskin

ds.h should not be including linux/device.h when compiling userspace
code.

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

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