/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

into groveronline.com:/root/bk/linux-acpi

I had to move the rtnetlink_init and init_netlink calls to af_netlink init time, so that
the sk_alloc called down the rtnetlink_init callchain is done after the PF_NETLINK
net_proto_family is sock_registered, and because of that the af_netlink init function
call had to be moved to earlier by means of subsys_initcall (DaveM's suggestion).

This fixes a mismatch in declaration between "irport_interrupt" in the
header files (returning void) and in the definition (returning
irqreturn_t).

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

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

request_irq requires a handler that returns irqreturn_t,
so mm_interrupt now returns the appropriate value

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

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

This fixes a problem with drivers that have request on the stack for
some operations, like IDE.  If we wake before releasing the request, the
stack may have already disappeared beneath us when the rest of
end_that_request_last() is run.

Fix by making sure the completion is done _last_.