The following patch removes the old framebuf_size and framebuf_read_start
values from the cam structure and simplifes the read function. It also
moves the needs dummy read check into the read_frame function. cp and dd
should both still work.

Inlined are a few more patches to 2.5.43 that fix problems that
were discovered during QA.

1-firm4.07 :: I've moved to the bottom since it's huge

Updates the firmware to 4.07. Fixes a bug introduced in 4.05 where
RTS is high after boot. Also fixes a bug where the whiteheat would
allow data reception after boot when no ports were open.

2-fix-dtr-rts

I didn't know this, but the firmware open command also handles
raising the signals for me. This code is superflous.

3-fix-read-urb

Read polling was started right away in whiteheat_open(). Coupled
with the firmware bug fixed above where data could be received
by a port that wasn't open, this caused the whiteheat_read_callback
to fire before open() was finished, and in some cases this caused
harm to the tty layer. I didn't track down the exact mechanism
because either moving the read polling to the last operation of open()
or using the fixed firmware caused the crash to stop happening. I
have stack traces if you'd like to have a look; it looks like something
scribbles on the stack, but I couldn't figure out what eactly, as the
scribbled data didn't match anything in the whiteheat driver or the
test applications.

4-fix-ixoff

RELEVANT_IFLAG masks off the software flow control bits, so that
a change that is restricted to the soft flow bits will be ignored. This
is the email I sent earlier; I've decided to just not use the macro for
now, but I'd still like to know if the macro should be fixed,.

..Stu

This is a slightly cleaned up version of that earlier patch:

- Makes both copies of the clear_halt() logic know that
   usb_pipein() returns boolean (zero/not) not integer (0/1).
   This resolves a problem folk have had with usb-storage.
   (I looked at kernel uses of usb_pipein and it really was
   only the clear_halt logic that cares.)

- Removes some code from the "standard" version; no point
   in Linux expecting devices to do something neither Microsoft
   nor Apple will test for.

This is Pavel's patch, with some cleanups and re-sorting of
the various SA-1100 cases.  According to Pavel this works
as well as his earlier version ... which is to say, maybe
not yet, he saw a uhci "very bad" error (on 2.5.43).

I'm sending it along since it's clearly the right way to
support the Zaurus, and it can't be that far off given the
code I've seen.

This should resolve the problems Nicolas Mailhot reported,
where an old BIOS seemed reluctant to release the controller
and the dbg() message delayed things enough to work.  At
worst, it'll eliminate dbg() messages as a factor.

Thanks to Hiroyuki ARAKI <hiro@zob.ne.jp> for the information.

The problem was that when the refcount hit 0, it was unconditionally
assuming that it had been added, which is wrong.  The patch below
corrects that, and fixes the Oops when loading the floppy driver.

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

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

Several ports (x86-64,ppc64,sparc64) which do 32bit ioctl emulation
have functions for drivers to let them define their own translation
handlers. So far it was a bit complicated to use because there
was no standard include file that declares the prototypes for this
stuff. Then drivers and other subsystems can start to declare their own
ioctl translation handlers.

This patch add include/linux/ioctl32.h to fix this.

The actual implementation is in arch specific code. It has been coordinated
with DaveM and Anton.

This patch is needed for the x86-64 merge I sent in separate mail.

There is currently no preprocessor symbol that the drivers can test
to see if they should use this. So far they have to check arch symbols.
This will be fixed later when all 64bit ports that need it add the dynamic
ioctl registration API too (that's ia64,s390x,mips64)

This fixes a few files that got lost with the last merge and merges
with 2.5.43/i386.  Only changes architecture specific files.

It depends on one other patch (for linux/ioctl32.h) which I'm sending
separately.

Changes:
- Include missing files (pageattr.c) and Makefile changes
- Update IA32 subsystem. Various small fixes and a big merge
  with sparc64.
- Change HZ to 1000
- Merge some of the 2.5.43/i386 profiling changes. No full oprofile yet.
- Fix many warnings
- Update defconfig
- Various other smaller cleanups and bugfixes.

        * switched to private queues
        * set ->queue

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

        * switched to private queues
        * set ->queue and ->private_data
        * switched to use of ->bd_disk/->rq_disk
        * merged private blocksize, etc. arrays into nbd_dev[]
        * cleaned up

        * switched to private queues
        * set ->queue and ->private_data
	* switched to use of ->rq_disk

	sbpcd.c: removes bogus duplicate definition of sbpcd_lock, use of
CURRENT (we are using private queue) and call of invalidate_buffers() in
->media_changed() (caller does it itself).  That went in a changeset from
davej - looks like a merge problem...
	sr.c: braino in ifdefed printk - s/disk/cd->disk/.  Thanks to jejb
for spotting that one...

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

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

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

This adds a set of list macros that make handling of list protected
by RCU simpler. The interfaces added are -

list_add_rcu
list_add_tail_rcu
	- Adds an element by taking care of memory barrier (wmb()).

list_del_rcu
	- Deletes an element but doesn't re-initialize the pointers in
	  the element for supporting RCU based traversal.

list_for_each_rcu
__list_for_each_rcu
	- Traversal of RCU protected list - takes care of memory barriers
	  transparently.

This first RCU helper patch adds a read_barrier_depends() primitive
to all archs which is NOP for archs that doesn't require an rmb()
for data dependent reads when writes are ordered using a wmb().
In reality, only alpha requires an rmb(), the rest are NOPs.
It is likely to be necessary in most situations that would use RCU.
Please apply.

 Description :

Sometime ago, during a discussion on lock-free lookups, it was
agreed that an additional memory barrier interface,
read_barrier_depends() that is lighter than an rmb(),
is necessary to make sure that data-dependent reads are not
re-ordered over this barrier. For many processors, data-dependency
enforces order, so this interface is a NOP, but for those that don't
(like alpha), it can be a rmb().

For example, the following code would force ordering (the initial
value of "a" is zero, "b" is one, and "p" is "&a"):

    CPU 0                           CPU 1

    b = 2;
    memory_barrier();
    p = &b;                         q = p;
                                    read_barrier_depends();
                                    d = *q;

because the read of "*q" depends on the read of "p" and these
two reads should be separated by a read_barrier_depends().  However,
the following code, with the same initial values for "a" and "b":

    CPU 0                           CPU 1

    a = 2;
    memory_barrier();
    b = 3;                          y = b;
                                    read_barrier_depends();
                                    x = a;

does not enforce ordering, since there is no data dependency between
the read of "a" and the read of "b".  Therefore, on some CPUs, such
as Alpha, "y" could be set to 3 and "x" to 0.  rmb()
needs to be used here, not read_barrier_depends().

The original discussion can be found at -
http://marc.theaimsgroup.com/?t=100259422200002&r=1&w=2

Explanation of the need for read_barrier_depends()
can be found at http://lse.sf.net/locking/wmbdd.html

This fixes a 'used but not declared' compile error

It ends up trying to list_del() from an uninitialized
list_head.

- Ignore queries for invalid addresses
- MLD for link-local addresses

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

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

- Change {udp,raw}_sendmsg to ip_append_data, work done
by Maxim Giryaev <gem@asplinux.ru>
- Get rid of ip_build_xmit() and helper functions.
Nobody uses it anymore.

The included patch is essentially a Linux Plug and Play Support rewrite.  It
contains many significant improvements, including the following:


1.)  A Global Plug and Play Layer
    - Now drivers do not have to worry about which plug and play
      protocol they are using.  Calls are made directly to the Linux
      Plug and Play Layer and then forwarded to the appropriate
      protocol.
    - This will make it very easy to integrate ACPI PnP support when
      it's ready


2.)  A complete Plug and Play BIOS driver
    - The Plug and Play BIOS now supports reading and writing of
      resource configurations.
    - It is now possible to enable disabled PNPBIOS devices.  Therefore
      the user can safely enable PnP OS support in their BIOS.


3.)  Driver Model Integration
    - The entire plug and play layer is integrated into the driver model
    - The user interface is housed here
    - PnP protocols are listed under the bus "pnp"


4.)  A powerful global resource configuration interface
    - The user can use this to activate PnP devices for legacy and
      user-level drivers
    - See the documentation for how to configure devices.

5.)  Automatic resource allocation for needed devices


6.)  A PnP device name database

And many more improvements.

This patch also adds me to the maintainers list, considering the current
PnP maintainer has been inactive for over 2 years now.

kill the machine.

Damn I hate people who kill the machine for no good reason.