drivers/char/sx.c converted to dynamic allocation

drivers/macintosh/macserial.c converted to dynamic allocation

drivers/sbus/char/aurora.c converted to dynamic allocation

drivers/tc/zs.c converted to dynamic allocation

drivers/sgi/char/sgiserial.c converted to dynamic allocation

drivers/serial/mcfserial.c converted to dynamic allocation

drivers/serial/68360serial.c converted to dynamic allocation

drivers/serial/68328serial.c converted to dynamic allocation

drivers/serial/core.c converted to dynamic allocation

net/bluetooth/rfcomm/tty.c converted to dynamic allocation

net/irda/ircomm/ircomm_tty.c converted to dynamic allocation

killed the last remnants of callout stuff - we don't need to mess with
storing termios privately anymore.

added helper functions for allocation and freeing tty_driver

->table[], ->termios[] and ->locked_termios[] allocated dynamically
in tty_register_driver() and freed in tty_unregister_driver().  Per-driver
arrays gone.

->refcount switched from int * to int.  Per-driver variables gone since we had
switched from int foo = 0; driver.refcount = &foo; to driver.refcount = 0;

Fixes a couple of leaks in char_dev.c

From: Samuel Thibault <Samuel.Thibault@ens-lyon.fr>

Tioclinux() uses "magic numbers" that applications should know to use it.
Here is a patch which adds an include/linux/tiocl.h which holds them and
can be used by applications to properly call iotcl(TIOCLINUX).  It might
stand for documentation as well, replacing the not up-to-date man
ioctl_list.

A structure for the selection argument is also defined.

From: Dipankar Sarma <dipankar@in.ibm.com>

Free any read channel allocated earlier if allocation of write channel
fails.  (From 2.4).

From: Dipankar Sarma <dipankar@in.ibm.com>

Fix memory leak - free on copyin failure.

From: Dipankar Sarma <dipankar@in.ibm.com>

Fix memory leak in emu10k1_audio_open.

From: Dipankar Sarma <dipankar@in.ibm.com>

Use copy_to_user to copy mpu_synth_ioctl arg.

From: Dipankar Sarma <dipankar@in.ibm.com>

Use copy_to_user/get_char with user buffers.

From: Dipankar Sarma <dipankar@in.ibm.com>

Fixed copy/user problem in lento_symlink where user address was getting
passed to presto_do_symlink.  (From 2.4)

From: Dipankar Sarma <dipankar@in.ibm.com>

Use copy_to_user, not memcpy with user buffers

From: Dipankar Sarma <dipankar@in.ibm.com>

Fix parsing of options for X.25 facilities

From: Jeff Muizelaar <muizelaar@rogers.com>

This patch against 2.5.70-bk2 removes the buffer allocation from resource.c
and lets seq_read do it instead.

From: Hugh Dickins <hugh@veritas.com>

Remove shmem_nrpages, no use is made of it (even 2.4-ac, though it counts
it, does nothing with it): reintroduce if it becomes useful.  Replace GPL
oneliner by the block from 2.4-ac, extend Copyright to 2003, remove two
white spaces.

From: Hugh Dickins <hugh@veritas.com>

Dissatisfied with earlier fix to race where swapoff sneaks page into tmpfs
page cache after truncate_inode_pages cleaned it: calling it a second time
can be too heavy, instead fix shmem_unuse_inode to check i_size.
(Actually, one part of this fix is in the previous patch: shmem_file_write
now has a hold on the page when it raises i_size.)

From: Hugh Dickins <hugh@veritas.com>

generic_file_aio_write_nolock has recently been corrected for when partial
writes hit -EFAULT: now bring shmem_file_write into line.

From: Hugh Dickins <hugh@veritas.com>

loop_get_buffer loses PF_MEMDIE if it's added while in loop_copy_bio: not a
high probability since it's not waiting there, but could happen, and sets a
bad example (compare with add_to_swap fixed a while back).

From: Hugh Dickins <hugh@veritas.com>

loop_copy_bio uses one gfp_mask for bio_alloc and alloc_page calls.  The
bio_alloc obviously can't use highmem, but the alloc_page can.  Yes, the
underlying device might be unable to use highmem, and have to use one of
its bounce buffers, with an extra copy: so be it.

(Originally I did propagate the underlying device's bounce needs down to
the loop device, to avoid that possible extra copy; but let's keep this
simple, the low end doesn't have highmem and the high end can I/O it.)

From: Hugh Dickins <hugh@veritas.com>

What purpose does loop_make_request's blk_queue_bounce serve?  None, it's
just a relic from before the kmaps were added to loop's transfers, and ties
up mempooled resources - in the file-backed case, with no guarantee they'll
soon be freed.  And what purpose does loop_set_fd's blk_queue_bounce_limit
serve?  None, blk_queue_make_request did that.

From: Hugh Dickins <hugh@veritas.com>

Jonah Sherman <jsherman@stuy.edu> pointed out back in February how
LO_FLAGS_BH_REMAP is never actually set, since loop_init_xfer only calls
the init for non-0 encryption type.  Fix that or scrap it?  Let's scrap it
for now, that path (hacking values in bio instead of copying data) seems
never to have been tested, and adds to the number of paths through loop:
leave that optimization to some other occasion.

From: Hugh Dickins <hugh@veritas.com>

Remove unused IV from loop_make_request (loop_transfer_bio does that).

From: Hugh Dickins <hugh@veritas.com>

Remove copy flag and code from loop_copy_bio: wasn't used when reading, and
waste of time when writing - the loop transfer function does that.  And
don't initialize bio fields immediately reinitialized by caller.

From: Hugh Dickins <hugh@veritas.com>

Now it's in loop not bio, better rename bio_copy to loop_copy_bio: loop
prefers names that way; and bio_transfer better named loop_transfer_bio.
Rename bio,b to rbh,bio to follow call from loop_get_buffer more easily.

From: Hugh Dickins <hugh@veritas.com>

bio_copy is used only by the loop driver, which already has to walk the bio
segments itself: so it makes sense to change it from bio.c export to loop.c
static, as prelude to working upon it there.

bio_copy itself is unchanged by this patch, with one exception.  On oom
failure it must use bio_put, instead of mempool_free to static bio_pool:
which it should have been doing all along - it was leaking the veclist.

(Grudgingly acked by Jens)

From: Hugh Dickins <hugh@veritas.com>

When loop restricts underlying file's allocation mask to avoid deadlock, it
unintentionally masks out its highmem capability, making failures at the
underlying level much more likely.

From: "Ni, Michael" <Michael.Ni@hp.com>

s/Compaq/HP/ in MAINTAINERS.

From: Christoph Hellwig <hch@lst.de>

currently only x86_64 and ia64 don't use the generic irq_cpustat code
and both have to workaround it's brokenness for the non-default case.

x86_64 defines an empty irq_cpustat_t even if it doesn't need one and
ia64 adds CONFIG_IA64 ifdefs around all users.  What about this patch
instead to make __ARCH_IRQ_STAT useable?