Remove "suspended" flag, queue plugging/unplugging and associated
checks, remove check for oversized requests.

Calculate data timeout correctly.
Obtain MCLK rate from clock subsystem.
Limit max clock rate properly.
Use clock bypass mode for fast data rates.

- Wait for STAT_CLK_EN to clear rather than waiting for the CLK_IS_OFF
  interrupt when stopping the MMC clock.
- Always return the number of data blocks transferred no matter what.
- Set the device driver data correctly.

This patch adds support for the Intel PXA MCI interface.

This patch adds initial support for the ARM MMCI Primecell - one of
the drivers for a MMC interface.

Since this is currently ARM-only, I've dropped the drivers/Kconfig
change for the time being.

This patch adds core support to the Linux kernel for driving MMC
interfaces found on embedded devices, such as found in the Intel
PXA and ARM MMCI primecell.  This patch does _not_ add support
for SD or SDIO cards.
                                                                                
It is vaguely based upon the handhelds.org MMC code, but the bulk
of the core has been rewritten from scratch.

From: <mikem@beardog.cca.cpqcorp.net>

This patch adds support for 2 new controllers.  The first is a PCI-Express
version of the 6400.  The second is actually a SATA controller using the cciss
interface.

   Accept negative level3cnt value in register_application
   for special b-channel calculation. Necessary to work with
   capidrv.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Based on information provided by "Allen Martin" <AMartin@nvidia.com>:

A hang is caused when the CPU generates a very fast CONNECT/HALT cycle
sequence.  Workaround is to set the SYSTEM_IDLE_TIMEOUT to 80 ns.
This allows the state-machine and timer to return to a proper state within
80 ns of the CONNECT and probe appearing together.  Since the CPU will not
issue another HALT within 80 ns of the initial HALT, the failure condition
is avoided.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into debian.org:/usr/src/kernel/ieee1394-2.6

Here is an updated lapic NMI ownership tracking patch which
should address the issues that were raised with the first one:

- Simplified the API function names to {reserve,release}_lapic_nmi().

- Rewrote the ownership tracking code to use two individually named
  flags instead of using arithmetic and the sign. The code is now
  simple enough that no "hiding" macros are needed. (Thanks Albert
  for that suggestion.)

degerrit@web.de wrote:
   "I caused an oops in unusual circumstances by accidentally "forcing" a
    video device number which was too high or already taken (don't know
    which). I assume this probably shouldn't give an oops (though it was my
     fault), so here's a bugreport..."

Fixed by adding a range check for the number passed in by the driver.

From: Hugh Dickins <hugh@veritas.com>

Remove this development-only debug code - Hugh thinks that its BUG_ON() can
trigger by accident.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

This adds some initial support for the latest model of iBook G4 (still
need some work on the clock chip at least and some radeonfb updates that
I'll send later along with other fixes for this driver). 

It also removes a useless delay and fixes detection of the airport card
on the "Windtunnel" class desktop G4 machines.

Those were missing from ppc32, please apply.

Heh, I moved 6 month ago, time to update CREDITS ;)

This cleans up the code used to initialize the 970 CPU.

More specifically, it adds support for the 970FX, makes sure we don't
touch registers we aren't supposed to when running in LPAR mode, and
stop blindly zeroing out HID4 and HID5, we just clear the bits we really
want clear in there and leave the rest to the firmware.

During mqueue_get_inode(), it's possible that kmalloc() of the
info->messages array will fail.  This failure mode will cause the
queues_count to be (incorrectly) decremented twice.  This patch uses
info->messages on mqueue_delete_inode() to determine whether the
mqueue was every truly created, and hence proper accounting is needed
on destruction.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Patch from Bjorn Helgaas

This adds efi_uart_console_only() so we can default to using a serial
console if the EFI console path only contains UARTs.

Patch from Alex Williamson

Here's a trivial patch that makes 8250_hcdp setup the correct flags
when IRQ sharing is enabled for serial ports.

The HCDP table tells us if the device is a PCI UART.  We can use this
to set the shared interrupt flag as well as program the interrupt with
the correct polarity/trigger (should get rid of "changing vector <x>
from IO-SAPIC-edge to IO-SAPIC-level" messages at bootup).  This also
allows non-PCI UARTs to be left un-shareable, which is likely much
more safe (edge triggered).

The bit that I'm keying on is still part of the older 1.0a HCDP spec,
so should be implemented (it was on all the boxes I tested).  If
there's firmware out there that doesn't set this bit or the interrupt
supported flag, the HCDP UART may run in polling mode, but should
still be functional.

Patch from Slawomir Kolodynski

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Patch from Daniel Ritz.

This patch clears an almost undocumented EnE specific test register
that makes sound on RME Hammerfall DSP Carbus work...should even work
after suspend.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

This fixes a potential oops/use after free bug, and removes an unused
variable warning.

From: <Andries.Brouwer@cwi.nl>

In the old days the printk log buffer had a constant size, and dmesg asked
for the 4096, later 8192, later 16384 bytes in there.  These days the
printk log buffer has variable size, and it is not easy for dmesg to do the
right thing, especially when doing a "read and clear".  The patch below
adds a syslog subfuntion that reports the buffer size.

Move error handling to capture all three possible error conditions on
sending to a full queue.  Without this fix any unprivileged user can
leak arbitrary amounts of kernel memory.