Mips RLIMIT_MEMLOCK incorrectly defaults to unlimited, it was confused with
RLIMIT_NPROC.  Found while consolidating resource.h headers.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

drivers/acpi/debug.c:22: parse error before string constant
drivers/acpi/debug.c:22: warning: type defaults to `int' in declaration of `__MODULE_INFO'
drivers/acpi/debug.c:22: warning: function declaration isn't a prototype
drivers/acpi/debug.c:22: warning: data definition has no type or storage class
drivers/acpi/debug.c:23: parse error before string constant
drivers/acpi/debug.c:23: warning: type defaults to `int' in declaration of `__MODULE_INFO'
drivers/acpi/debug.c:23: warning: function declaration isn't a prototype
drivers/acpi/debug.c:23: warning: data definition has no type or storage class
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

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

Spotted by Marco Cipullo
Signed-off-by: Dave Jones <davej@redhat.com>

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

From: Hendrik Muhs
Signed-off-by: Dave Jones <davej@redhat.com>

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

Patch from Ben Dooks

Remove static mapping for serial ports and change
to using UPF_IOREMAP to allow the serial driver to
automatically ioremap() the ports for us.

Signed-off-by: Ben Dooks
Signed-off-by: Russell King

Patch from Ben Dooks

_find_first_zero_bit_le and _find_next_zero_bit_le are missing the
const from their pointer arguments, causing the following warnings:
In file included from mm/page_alloc.c:34:
include/linux/nodemask.h: In function `__first_unset_node':
include/linux/nodemask.h:246: warning: passing arg 1 of `_find_first_zero_bit_le' discards qualifiers from pointer target type

Signed-off-by: Ben Dooks
Signed-off-by: Russell King

This re-implements the nonintrusive spin-polling loop for the
SMP+PREEMPT spinlock/rwlock variants, using the new *_can_lock()
primitives.  (The patch also adds *_can_lock() to the UP branch of
spinlock.h, for completeness.)

build- and boot-tested on x86 SMP+PREEMPT and SMP+!PREEMPT.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This renames the x86 implementation of the spinlock_t's 'lock' field to
'slock', to protect against spinlock_t/rwlock_t type mismatches.

This way, if you use a spinlock where a rwlock is expected (or vice
versa), you'll get an obvious compile failure.

build- and boot-tested on x86 SMP+PREEMPT and SMP+!PREEMPT.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Trivial but untested (but also currently unused - wait
for BKL PREEMPT to start using them soon).

This introduces the following 3 new locking primitives:

  spin_can_lock(lock)
  read_can_lock(lock)
  write_can_lock(lock)

which are a nonintrusive test to check whether the real (intrusive)
trylock op would succeed or not.  Semantics and naming is completely
symmetric to the trylock counterpart.

Architectures that want to support PREEMPT will need to add these
definitions.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

cleanup: remove stale semicolon from linux/spinlock.h and stale space
from asm-i386/spinlock.h.

	Ingo
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

It's a bootup dependancy, you can't just increase it randomly, and
it breaks booting with LILO.

Pointed out by Janos Farkas and Adrian Bunk.

Cset exclude: ak@suse.de[torvalds]|ChangeSet|20050115232300|01174

rwlocks can't be "locked". They can be "locked for read", or
"locked for write", but not both. The confusion this caused is
evident in the long discussion about this on linux-kernel ;)

They had their time and place, but right now they are using
infrastructure that is getting re-done, and we're better off
just dropping them.

The locking tests were wrong, and the fixes are up in the air. In the
meantime, the get-it-working patch is to just not do this.

Cset exclude: mingo@elte.hu[torvalds]|ChangeSet|20050115174045|30241

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

into flint.arm.linux.org.uk:/usr/src/bk/linux-2.6-rmk

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

My ALPS touchpad is not recognized because the device gets confused by
the Kensington ThinkingMouse probe.  It responds with "00 00 14"
instead of the expected "00 00 64" to the "E6 report".

Resetting the device before attempting the ALPS probe fixes the
problem.
Signed-off-by: Peter Osterlund <petero2@telia.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

We could screw up and warn for opcodes that weren't write-safe and the
user tried to use without having write permissions.

Not so bad in itself, but that also destroyed the cmd type information.

Noticed by Michal Schmidt

We don't practically use ipimask for anything anymore; remove it.

Rather than having an assembly and C version performing the same
lookup, re-use the assembly version with a C wrapper around it.
This removes the duplication.
Signed-off-by: Russell King <rmk@arm.linux.org.uk>

From: Christoph Hellwig
Signed-off-by: Dave Jones <davej@redhat.com>

into delerium.kernelslacker.org:/mnt/data/src/bk/agpgart

- any device teardown must happen between agp_remove_bridge and
  agp_put_bridge, before agp_remove_bridge users can still call into
  the code
- it's releasing a reference to the wrong device

Original patch from: Christoph Hellwig
Further munging from Roland Dreier and myself.
Signed-off-by: Dave Jones <davej@redhat.com>

From: Christoph Hellwig
Signed-off-by: Dave Jones <davej@redhat.com>

From: Alan Hourihane
Signed-off-by: Dave Jones <davej@redhat.com>

When drivers other than loopback were using the LLTX
feature a race window was present.  While sending
queued packets, the packet scheduler layer drops the
queue lock then calls directly into the drivers xmit
handler.  The driver then grabs it's private TX lock
and goes to work.

However, as soon as we've dropped the queue lock another
thread doing TX processing for that card can execute
a netif_stop_queue() due to the TX queue filling up.
This race window causes problems because a properly coded
driver should never end up in it's ->hard_start_xmit()
handler if the queue on the device has been stopped and
we even BUG() trap for this condition in all of the device
drivers.  That is how this race window was discovered
by Roland and the Infiniband folks.

Various suggestions were made to close this race.  One
of which involved holding onto the queue lock all the
way into the ->hard_start_xmit() routine.  Then having
the driver drop that lock only after taking it's private
TX lock.  This solution was deemed grotty because it is
not wise to put queueing discipline internals into the
device drivers.

The solution taken here, which is based upon ideas from
Stephen Hemminger, is twofold:

1) Leave LLTX around for purely software devices that
   need no locking at all for TX processing.  The existing
   example is loopback, although all tunnel devices could
   be converted in this way too.

2) Stop trying to use LLTX for the other devices.  Instead
   achieve the same goal using a different mechanism.

For #2, the thing we were trying to achieve with LLTX
was to eliminate excess locking.  We accomplish that
now by letting the device driver use dev->xmit_lock directly
instead of a seperate priv->tx_lock of some sort.

In order to allow that, we had to turn dev->xmit_lock into
a hardware IRQ disabling lock instead of a BH disabling one.
Signed-off-by: David S. Miller <davem@davemloft.net>

into flint.arm.linux.org.uk:/usr/src/bk/linux-2.6-rmk

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

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

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

into coreworks.de:/home/kaber/src/net/net-2.6-sched

Both HFSC and CBQ leak unclassified skbs with CONFIG_NET_CLS_ACT.
Move freeing to enqueue where it belongs. Same change for in HTB/prio,
they just don't leak because they don't have unclassified packets.
Signed-off-by: Patrick McHardy <kaber@trash.net>

handle is computed wrong, this makes creating a filter not using
"from" fail.
Signed-off-by: Patrick McHardy <kaber@trash.net>