an input device from other handlers and have an exclusive access
to events.

Reduce MAX_MEM_LEVEL to 8.  This reduces zlib memory consumption by
128k (from ~400k to ~270k) at the theoretical cost of worse
compression.  No code currently in the kernel actually uses the better
compression, so the practical cost is zero.

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

chr_dev_init() should be a subsys_initcall(), since it needs to
initialize before any drivers that use the character device
infrastructure.

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

into mars.ravnborg.org:/home/sam/src/linux/kernel/bk/docbook

into kanga.twiddle.net:/home/rth/work/linux/axp-2.5

from the MAINTAINERS list. How they're HP, and maintained
by Stephen Cameron.

More merging from zlib-1.1.4

force windowBits > 8 to avoid a bug in the encoder for a window size
of 256 bytes. (A complete fix will be available in 1.1.5).

James Carlson:

        The problem is that s->strstart gets set to a very large
        positive integer when wsize (local copy of s->w_size) is
        subtracted in deflate.c:fill_window().  This happens because
        MAX_DIST(s) resolves as a negative number when the window size
        is 8 -- MAX_DIST(s) is defined as s->w_size-MIN_LOOKAHEAD in
        deflate.h.  MIN_LOOKAHEAD is MAX_MATCH+MIN_MATCH+1, and that
        is 258+3+1 or 262.  Since a window size of 8 gives s->w_size
        256, MAX_DIST(s) is 256-262 or -6.

        This results in read_buf() writing over memory outside of
        s->window, and a crash.

Don't think anyone actually bothers to check specific error codes, but
it shouldn't hurt either.

This removes unnecessary NULL casting.

s/Z_NULL/NULL/g.

Simple s/local/static/.

They may have some new HP address, unknown for now.

Most of it is reformatting, but the functional bits should fix real
problems.  A loop is introduced, just like in the turboc patch and one
of the three condition bodies has been expanded.

This is the first bit of the missing merge towards 1.1.4.  Applies on
top of the previous cleanups.

This one rips out an ugly #ifdef and seems to catch a theoretical
error possibility.  Always thought that they fixed more than they
officially admitted.

We don't use any cplusplus in the kernel.

The old 26-bit ARM support was long since dropped out of the regular ARM
support, since it was different enough to not make sense to maintain as
one port.

This re-introduces arm26 as an architecture of its own.

lib-y is the new way to define what objects belongs to a library.  The
implementation was not made backwards compatible and therefore an update
to all architectures are needed.

This is a simple replacement of obj-* to lib-* and deletion of L_TARGET.
The new mechanish where lib.a can be mixed with built-in.o is not
utilised.

into mars.ravnborg.org:/home/sam/src/linux/kernel/bk/v2.5

The location between the comment and the prototype confused kernel-doc.
Kernel-doc requires the prototype to follow after the comment section.

Previously kernel-doc silently ignored missing parameter descriptions
but sometimes 'make sgmldocs' failed with exit code > 0.
When kernel-doc encounter parameters where the description is missing
it now prints a warning.
docproc corrected so previously exit code are recorded.
docbook makefile cleaned up a bit

Adapted comments to follow what kernel-doc (docbook) understands

Path to pci_hotplug_core corrected.
Added !Eli/string.h to document strlcpy and friends

- rewrite taskfile PIO handlers
  (they now comply with ide state machine and use bio walking)
- switch ide-disk.c to use *only* taskfile IO
- swicth pdc4030.c to use *only* taskfile IO (untested)
- remove old cruft (>600 lines)

From: Davide Libenzi <davidel@xmailserver.org>

After the ep_remove() the "epi" is given back to the cache, so "epi->ep"
might become invalid.  It was not cought by my tests because the element
wasn't immediately reused (and because I was using a single epoll fd, so
the "ep" item remained the same).

From: Dave Hansen <haveblue@us.ibm.com>

__alloc_bootmem_core() has a couple of BUG_ON()'s.  Since the handlers
aren't set up this early, if you hit it, you just get along stream of
"Unknown Interrupt" messages.  It would be very nice to have a little
bit more information when something has decided to BUG() out this
early.

Christoph says this undef is not correct.