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

- access SA1111 GPIO using sa1111_set_io functions.
- access Lubbock misc register using lubbock_set_misc_wr
- fix CF voltage selection.
- don't fiddle with PCMCIA voltage selection when selecting CF
  voltage.
- wait for the voltage switches to stabilise before reading the
  new card state.

Patch from Ian Campbell

The recent changeset "Sanitise handling of unneeded syscall stubs" missed

__ARCH_WANT_SYS_PAUSE from include/asm-arm/unistd.h.

Disabling IRQs over context switches causes unreasonable IRQ latency
on VIVT cached machines, so provide our own prepare_arch_switch(),
finish_arch_switch() and task_running() implementations.  We provide
an optimised UP version so we don't end up needlessly incrementing
and decrementing the preempt count.

These are supposed to be ordered by option name.

Using these old definitions on PXA will result in randomly
scribbling over memory.  Remove them.

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

Any architecture (like pa-risc) that makes use of the helper function
flush_dcache_mmap_lock() won't compile with the new rmap due to use of
the wrong "mapping". 

Trivial fix.

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

- There are only 16 entries in the pseudo palette
- For dual-panel displays, we need to halve the display height
- When disabling the LCD controller, use LCCR0_DIS (aka slow disable)
  rather than quick disable.
- Clean up compiler warnings.

Some SA1111 devices are unable to clear the PS/2 receive IRQ before
it has been serviced, so we always re-enter the handler one more
time than is strictly necessary.  We can't clear the IRQ after
servicing because that causes race conditions with other SA1111
devices, so we take the easy option and always return IRQ_HANDLED.

- Move CKEN manipulation into power management handling (so we don't
  shut down the clock to the console port.)
- .iotype should be using UPIO_xxx not SERIAL_IO_xxx
- Remove each port when module is unloaded.
- Remove needless #include.
- Remove ASYNC_SKIP_TEST - we don't have any tests to skip.

This provides an atomic method to update the Lubbock board specific
register from various drivers.

Fix an oops caused by a missing failure return value for devices which
do not require DMA bouncing.

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

PCM Midlevel,ALSA Core
Added SNDRV_PCM_SYNC_PTR_APPL and SNDRV_PCM_SYNC_PTR_AVAIL_MIN extensions
to SYNC_PTR ioctl for PCM API.

VIA82xx driver
- added the DXS entry for ECS K7VTA3 v8.0
- fixed the DXS entry for ASUS A7V8X to NO_VRA.

ALSA Core
added reverse selections of components to CONFIG_SND_BIT32_EMUL.

PCI drivers,ICE1712 driver,ICE1724 driver
- improved the description of ice1724 driver on Kconfig.
- better support of VT1720 with snd-ice1724 driver.
- check PCI subsystem IDs when no EEPROM is available (ice1724 only)
- change the driver name string if given in the board list.
- merged prodigy 7.1 support into aureon.c.  they are almost identical.
- allow to use PDMA4 and RMDA1 for non-SPDIF purpose if specified (ice1724 only).

into nuts.davemloft.net:/disk1/BK/net-2.6

The PCMCIA devices are not devices for the kernel and the bt3c_cs
driver uses a fake device for calling request_firmware(). The fake
device initialization must also set .kobj.k_name to prevent an oops
until PCMCIA devices are fully integrated into the driver model.

It is not possible to use __module_get() when adding a new RFCOMM
session, because there is a case where no reference count is hold.
This happens when the module is not in use right now and an incoming
connection occurs.

Bump driver version

This patch removes all usage of anonymous unions from the ipr
driver since gcc 2.95 does not support anonymous unions.

This patch fixes an oops discovered in test which can occur
on bad hardware if the ipr adapter times out coming operational. 

This patch adds additional error logging to abort, device reset,
and bus reset paths to help in diagnosing scsi problems on ipr.

This patch fixes an issue where ipr was including a kernel
data structure, list_head, in a packed structure, which causes
compile issues on some architectures, and is just a bad thing to do.

From: 	Alan Cox <alan@redhat.com>

Pretty minimal. queue_command is now called locked, this requires propogating
some small locking changes for send_s870

This takes ncpfs ioctl handling into fs/compat_ioctl.c, removing it from
ppc64 and sparc64 code.

Code sanitized, switched to compat_alloc_user_space(), bunch of
{k,v}malloc() killed.

There is a longstanding bug in the rt_sigreturn system call.
This exists in both 2.4 and 2.6, and for almost every platform.

I am referring to this code in sys_rt_sigreturn (arch/i386/kernel/signal.c):

	if (__copy_from_user(&st, &frame->uc.uc_stack, sizeof(st)))
		goto badframe;
	/* It is more difficult to avoid calling this function than to
	   call it and ignore errors.  */
	/*
	 * THIS CANNOT WORK! "&st" is a kernel address, and "do_sigaltstack()"
	 * takes a user address (and verifies that it is a user address). End
	 * result: it does exactly _nothing_.
	 */
	do_sigaltstack(&st, NULL, regs->esp);

As the comment says, this is bogus.  On vanilla i386 kernels, this is just
harmlessly stupid--do_sigaltstack always does nothing and returns -EFAULT.

However this code actually bites users on kernels using Ingo Molnar's 4G/4G
address space layout changes.  There some kernel stack address might very
well be a lovely and readable user address as well.  When that happens, we
make a sigaltstack call with some random buffer, and then the fun begins.

To my knowledge, this has produced trouble in the real world only for 4G
i386 kernels (RHEL and Fedora "hugemem" kernels) on machines that actually
have several GB of physical memory (and in programs that are actually using
sigaltstack and handling a lot of signals).  However, the same clearly
broken code has been blindly copied to most other architecture ports, and
off hand I don't know the address space details of any other well enough to
know if real kernel stack addresses and real user addresses are in fact
disjoint as they are on i386 when not using the nonstandard 4GB address
space layout.

The obvious intent of the call being there in the first place is to permit
a signal handler to diddle its ucontext_t.uc_stack before returning, and
have this effect a sigaltstack call on the signal handler return.  This is
not only an optimization vs doing the extra system call, but makes it
possible to make a sigaltstack change when that handler itself was running
on the signal stack.  AFAICT this has never actually worked before, so
certainly noone depends on it.  But the code certainly suggests that
someone intended at one time for that to be the behavior.  Thus I am
inclined to fix it so it works in that way, though it has not done so before.
It would also be reasonable enough to simply rip out the bogus call and not
have this functionality.

From the current state of code in both 2.4 and 2.6, there is no fathoming
how this broken code came about.  It's actually much simpler to just make
it work!  I can only presume that at some point in the past the sigaltstack
implementation functions were different such that this made sense.  Of the
few ports I've looked at briefly, only the ppc/pc64 porters (go paulus!)
actually tried to understand what the i386 code was doing and implemented
it correctly rather than just carefully transliterating the bug.

The patch below fixes only the i386 and x86_64 versions.  The x86_64
patches I have not actually tested.  I think each and every arch (except
ppc and ppc64) need to make the corresponding fixes as well.  Note that
there is a function to fix for each native arch, and then one for each
emulation flavor.  The details differ minutely for getting the calls right
in each emulation flavor, but I think that most or all of the arch's with
biarch/emulation support have similar enough code that each emulation
flavor's fix will look very much like the arch/x86_64/ia32/ia32_signal.c
patch here.

From: Rajesh Venkatasubramanian <vrajesh@umich.edu>

This patch adds prefetches for walking a vm_set.list.  Adding prefetches
for prio tree traversals is tricky and may lead to cache trashing.  So this
patch just adds prefetches only when walking a vm_set.list.

I haven't done any benchmarks to show that this patch improves performance.
 However, this patch should help to improve performance when vm_set.lists
are long, e.g., libc.  Since we only prefetch vmas that are guaranteed to
be used in the near future, this patch should not result in cache trashing,
theoretically.

I didn't add any NULL checks before prefetching because prefetch.h clearly
says prefetch(0) is okay.

From: Hugh Dickins <hugh@veritas.com>

anon_vma rmap will always necessarily be more restrictive about vma merging
than before: according to the history of the vmas in an mm, they are liable to
be allocated different anon_vma heads, and from that point on be unmergeable.

Most of the time this doesn't matter at all; but in two cases it may matter.
One case is that mremap refuses (-EFAULT) to span more than a single vma: so
it is conceivable that some app has relied on vma merging prior to mremap in
the past, and will now fail with anon_vma.  Conceivable but unlikely, let's
cross that bridge if we come to it: and the right answer would be to extend
mremap, which should not be exporting the kernel's implementation detail of
vma to user interface.

The other case that matters is when a reasonable repetitive sequence of
syscalls and faults ends up with a large number of separate unmergeable vmas,
instead of the single merged vma it could have.

Andrea's mprotect-vma-merging patch fixed some such instances, but left other
plausible cases unmerged.  There is no perfect solution, and the harder you
try to allow vmas to be merged, the less efficient anon_vma becomes, in the
extreme there being one to span the whole address space, from which hangs
every private vma; but anonmm rmap is clearly superior to that extreme.

Andrea's principle was that neighbouring vmas which could be mprotected into
mergeable vmas should be allowed to share anon_vma: good insight.  His
implementation was to arrange this sharing when trying vma merge, but that
seems to be too early.  This patch sticks to the principle, but implements it
in anon_vma_prepare, when handling the first write fault on a private vma:
with better results.  The drawback is that this first write fault needs an
extra find_vma_prev (whereas prev was already to hand when implementing
anon_vma sharing at try-to-merge time).

From: Hugh Dickins <hugh@veritas.com>

Andrea Arcangeli's anon_vma object-based reverse mapping scheme for anonymous
pages.  Instead of tracking anonymous pages by pte_chains or by mm, this
tracks them by vma.  But because vmas are frequently split and merged
(particularly by mprotect), a page cannot point directly to its vma(s), but
instead to an anon_vma list of those vmas likely to contain the page - a list
on which vmas can easily be linked and unlinked as they come and go.  The vmas
on one list are all related, either by forking or by splitting.

This has three particular advantages over anonmm: that it can cope
effortlessly with mremap moves; and no longer needs page_table_lock to protect
an mm's vma tree, since try_to_unmap finds vmas via page -> anon_vma -> vma
instead of using find_vma; and should use less cpu for swapout since it can
locate its anonymous vmas more quickly.

It does have disadvantages too: a lot more change in mmap.c to deal with
anon_vmas, though small straightforward additions now that the vma merging has
been refactored there; more lowmem needed for each anon_vma and vma structure;
an additional restriction on the merging of vmas (cannot be merged if already
assigned different anon_vmas, since then their pages will be pointing to
different heads).

(There would be no need to enlarge the vma structure if anonymous pages
belonged only to anonymous vmas; but private file mappings accumulate
anonymous pages by copy-on-write, so need to be listed in both anon_vma and
prio_tree at the same time.  A different implementation could avoid that by
using anon_vmas only for purely anonymous vmas, and use the existing prio_tree
to locate cow pages - but that would involve a long search for each single
private copy, probably not a good idea.)

Where before the vm_pgoff of a purely anonymous (not file-backed) vma was
meaningless, now it represents the virtual start address at which that vma is
mapped - which the standard file pgoff manipulations treat linearly as vmas
are split and merged.  But if mremap moves the vma, then it generally carries
its original vm_pgoff to the new location, so pages shared with the old
location can still be found.  Magic.

Hugh has massaged it somewhat: building on the earlier rmap patches, this
patch is a fifth of the size of Andrea's original anon_vma patch.  Please note
that this posting will be his first sight of this patch, which he may or may
not approve.