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

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

Adds machine specific support for Ceiva Photoframe. Affects:
arch/arm/mach-clps711x/Makefile 
arch/arm/mach-clps711x/ceiva.c (new)
include/asm-arm/arch-clps711x/hardware.h
include/asm-arm/arch-clps711x/memory.h

Differences from 1st patch:
Removed redundant static I/O mapping for flash from hardware.h
Reverted to original CONFIG_DISCONTIGMEM enabling in memory.h
Added PHYS_TO_NID definition, when DISCONTIG undefined in memory.h

(From Thunder)

Two bugs here:

1) The return value of strchr("foo",0) should be the start address of
   "foo" + 3, not NULL.

2) Since the second argument for strchr() is defined as an int, some
   characters such as 'é' might validly end up to be the value -23 due to
   signedness issues.  Corectly handle those.

The return value from ptrace_set_bit() is never used.  This cset
makes it a void function.

This removes some minor differences between Linus' tree and the main
ARM tree; comment clarification and some weird formatting.

This keeps ARM in line with the continued transition to the input
layer.

Hi,
  I believe the comment in the nwfpe fpopcodes is slightly wrong -
although a 2nd pair of eyes on this would be a good idea.

Hi,
  For reasons of great complexity I found out the hard way that the
kernel must (and does) zero the pad sections in the stat structures.
Here is a comment that states this for the next person who needs to
know.

This allows the FP module to perform some extra optimisations.

Update for changes in mainline 2.5.3[01234].

This patch adds symlinks, hardlinks, device nodes, uid/gid, unix
permissions vs servers that support it (ie samba). Most of this is the
work of John Newbigin, I just modified it for 2.5.

There are issues with what samba allows (eg you can't make arbitrary
symlinks) and room for improvements (use the servers value for ino?). But
it doesn't affect "normal" users.

smbfs wants a wait_event_interruptible_timeout to be able to replace
interruptible_sleep_on_timeout.

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

into tp1.ruhr-uni-bochum.de:/home/kai/src/kernel/v2.5/linux-2.5.make

(slightly modified to unconditionally add the relative path to the subdir)

Rusty Russel wrote:

"M-x compile" in emacs stars a compilation and can jump to the next
error.  With KBUILD_VERSBOSE=0 (as I have in my env, great work Kai)
it can't figure out the directory, since it doesn't see the make[XXX]
markers.

This makes it work.

by Aristeu Sergio Rozanski Filho

Currently, scripts/Configure has code for the 'int' verb to take a
min/max.  This violates the spec described in
Documentation/kbuild/config-language.txt.  It also requires that if a
default is outside of +/- 10,000,000 that defaults be provided, or
'config' and 'oldconfig' will get stuck.  The following removes the
support for a min/max from scripts/Configure.

(by Tom Rini)

Update radeon_irq.c and reiserfs for tq simplifications

This removes some more old symbols from ksyms.c.  This makes the kernel
compile with modules enabled.

This add-on patch is needed to abort on Dell Inspiron 8000 / 8100 which
would lock up during speedstep.c and to resolve an oops (thanks to Hu Gang
for reporting this)

CPUFreq 24-API add-on patch for 2.5.39:
kernel/cpufreq.c	cpufreq-24-API
include/linux/cpufreq.h	cpufreq-24-API
arch/i386/config.in	Transmeta LongRun does not work well with cpufreq-24-API
arch/i386/Config.help	help text for CONFIG_CPU_FREQ_24_API

CPUFreq documentation for 2.5.39:
CREDITS			one further CREDIT entry
Documentation/cpufreq	documentation of CPU frequency and voltage scaling
	support in the Linux kernel.
MAINTAINERS		one further MAINTAINERS entry
arch/i386/Config.help	Config.help texts for i386 CPUFreq drivers

CPUFreq i386 drivers for 2.5.39:
arch/i386/config.in				Necessary config options
arch/i386/kernel/cpu/Makefile			allow for compilation of the CPUFreq subdirectory
arch/i386/kernel/cpu/cpufreq/Makefile		Makefile for CPUFreq drivers
arch/i386/kernel/cpu/cpufreq/elanfreq.c		CPUFreq driver for AMD Elan processors
arch/i386/kernel/cpu/cpufreq/longhaul.c		CPUFreq driver for VIA Longhaul processors
arch/i386/kernel/cpu/cpufreq/longrun.c		CPUFreq driver for Transmeta Crusoe processors
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	CPUFreq driver for Pentium 4 Xeon processors (using clock modulation)
arch/i386/kernel/cpu/cpufreq/powernow-k6.c	CPUFreq driver for mobile AMD K6-2+ and mobile AMD K6-3+ processors
arch/i386/kernel/cpu/cpufreq/speedstep.c	CPUFreq drivers for ICH2-M and ICH3-M chipsets and Intel Pentium 3-M and 4-M processors.

CPUFreq i386 core for 2.5.39:
arch/i386/kernel/i386_ksyms.c	export cpu_khz
arch/i386/kernel/time.c		update various i386 values on frequency
				changes
include/asm-i386/msr.h		add Transmeta MSR defines

CPUFreq core for 2.5.39
include/linux/cpufreq.h		CPUFreq header
kernel/Makefile			add cpufreq.c if necessary
kernel/cpufreq.c		CPUFreq core

More cleanups for the OSS sound modules

This is the smptimers patch plus the removal of old BHs and a rewrite of
task-queue handling.

Basically with the removal of TIMER_BH i think the time is right to get
rid of old BHs forever, and to do a massive cleanup of all related
fields.  The following five basic 'execution context' abstractions are
supported by the kernel:

  - hardirq
  - softirq
  - tasklet
  - keventd-driven task-queues
  - process contexts

I've done the following cleanups/simplifications to task-queues:

 - removed the ability to define your own task-queue, what can be done is
   to schedule_task() a given task to keventd, and to flush all pending
   tasks.

This is actually a quite easy transition, since 90% of all task-queue
users in the kernel used BH_IMMEDIATE - which is very similar in
functionality to keventd.

I believe task-queues should not be removed from the kernel altogether.
It's true that they were written as a candidate replacement for BHs
originally, but they do make sense in a different way: it's perhaps the
easiest interface to do deferred processing from IRQ context, in
performance-uncritical code areas.  They are easier to use than
tasklets.

code that cares about performance should convert to tasklets - as the
timer code and the serial subsystem has done already. For extreme
performance softirqs should be used - the net subsystem does this.

and we can do this for 2.6 - there are only a couple of areas left after
fixing all the BH_IMMEDIATE places.

i have moved all the taskqueue handling code into kernel/context.c, and
only kept the basic 'queue a task' definitions in include/linux/tqueue.h.
I've converted three of the most commonly used BH_IMMEDIATE users:
tty_io.c, floppy.c and random.c. [random.c might need more thought
though.]

i've also cleaned up kernel/timer.c over that of the stock smptimers
patch: privatized the timer-vec definitions (nothing needs it,
init_timer() used it mistakenly) and cleaned up the code. Plus i've moved
some code around that does not belong into timer.c, and within timer.c
i've organized data and functions along functionality and further
separated the base timer code from the NTP bits.

net_bh_lock: i have removed it, since it would synchronize to nothing. The
old protocol handlers should still run on UP, and on SMP the kernel prints
a warning upon use. Alexey, is this approach fine with you?

scalable timers: i've further improved the patch ported to 2.5 by wli and
Dipankar. There is only one pending issue i can see, the question of
whether to migrate timers in mod_timer() or not. I'm quite convinced that
they should be migrated, but i might be wrong. It's a 10 lines change to
switch between migrating and non-migrating timers, we can do performance
tests later on. The current, more complex migration code is pretty fast
and has been stable under extremely high networking loads in the past 2
years, so we can immediately switch to the simpler variant if someone
proves it improves performance. (I'd say if non-migrating timers improve
Apache performance on one of the bigger NUMA boxes then the point is
proven, no further though will be needed.)

Avoid racing on signal delivery with thread signal blocking in thread
groups.

The method to do this is to eliminate the per-thread sigmask_lock, and
use the per-group (per 'process') siglock for all signal related
activities.  This immensely simplified some of the locking interactions
within signal.c, and enabled the fixing of the above category of signal
delivery races.

This became possible due to the former thread-signal patch, which made
siglock an irq-safe thing.  (it used to be a process-context-only
spinlock.) And this is even a speedup for non-threaded applications:
only one lock is used.

I fixed all places within the kernel except the non-x86 arch sections.
Even for them the transition is very straightforward, in almost every
case the following is sufficient in arch/*/kernel/signal.c:

		:1,$s/->sigmask_lock/->sig->siglock/g

Fix thread-group SIGSTOP handling - the SIGSTOP notification was not
propagated to the parent of the thread group leader.  Now Ctrl-Z-ing of
thread groups works again.

Fix thread group signal sending

This fixes one more race left in the new futex hashing code, which
triggers if a futex waiter gets a signal after it has been woken up but
before it actually wakes up.