Update s30 for the signal race fix

From: Mikael Pettersson <mikpe@csd.uu.se>

  The signal-race-fixes patch in 2.6.8-rc2-mm1 appears to be a bit broken on
  s390.

  When forcing a SIGSEGV the old code updated "*ka", where ka was a pointer
  to current's k_sigaction for SIGSEGV.  Now "ka_copy" points to a copy of
  that structure, so assigning "*ka_copy" doesn't do what we want.  Instead do
  the assignment via current->...  just like i386 and x86_64 do.

  Furthermore, the SA_ONESHOT handling wasn't deleted.  That is now handled
  by generic code in the kernel.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The problem:

  In arch/i386/signal.c, in the do_signal() function, it calls
  get_signal_to_deliver() which returns the signal number to deliver (along
  with siginfo).  get_signal_to_deliver() grabs and releases the lock, so
  the signal handler lock is not held in do_signal().  Then the do_signal()
  calls handle_signal(), which uses the signal number to extract the
  sa_handler, etc.

  Since no lock is held, it seems like another thread with the same
  signal handler set can come in and call sigaction(), it can change
  sa_handler between the call to get_signal_to_deliver() and fetching the
  value of sa_handler.  If the sigaction() call set it to SIG_IGN, SIG_DFL,
  or some other fundamental change, that bad things can happen.

The patch:

  You have to get the sigaction information that will be delivered while
  holding sighand->siglock in get_signal_to_deliver().

  In 2.4, it can be fixed per-arch and requires no change to the
  arch-independent code because the arch fetches the signal with
  dequeue_signal() and does all the checking.

The test app:

  The program below has three threads that share signal handlers.  Thread
  1 changes the signal handler for a signal from a handler to SIG_IGN and
  back.  Thread 0 sends signals to thread 3, which just receives them.
  What I believe is happening is that thread 1 changes the signal handler
  in the process of thread 3 receiving the signal, between the time that
  thread 3 fetches the signal info using get_signal_to_deliver() and
  actually delivers the signal with handle_signal().

  Although the program is obvously an extreme case, it seems like any
  time you set the handler value of a signal to SIG_IGN or SIG_DFL, you can
  have this happen.  Changing signal attributes might also cause problems,
  although I am not so sure about that.

  (akpm: this test app segv'd on SMP within milliseconds for me)


#include <signal.h>
#include <stdio.h>
#include <sched.h>

char stack1[16384];
char stack2[16384];

void sighnd(int sig)
{
}

int child1(void *data)
{
	struct sigaction act;

	sigemptyset(&act.sa_mask);
	act.sa_flags = 0;
	for (;;) {
		act.sa_handler = sighnd;
		sigaction(45, &act, NULL);
		act.sa_handler = SIG_IGN;
		sigaction(45, &act, NULL);
	}
}

int child2(void *data)
{
	for (;;) {
		sleep(100);
	}
}

int main(int argc, char *argv[])
{
	int pid1, pid2;

	signal(45, SIG_IGN);
	pid2 = clone(child2, stack2 + sizeof(stack2) - 8,
			CLONE_SIGHAND | CLONE_VM, NULL);
	pid1 = clone(child1, stack1 + sizeof(stack2) - 8,
			CLONE_SIGHAND | CLONE_VM, NULL);

	for (;;) {
		kill(pid2, 45);
	}
}
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

And don't accept UTF translations as the start of a control
state either.

MDA is ISA-only ;-)

Several places did le16_to_cpup() on misaligned address, which blows on
any little-endian platform that doesn't like misaligned reads.

wrong type of return value.

Fixed assumption that char is always unsigned

Killed check_region(), fixed an old bug in ISA case (we checked the wrong
region before claiming the right one - dumb typo back in 2.4.early)

->sendfile() takes kernel pointer, not userland one.

->ki_buf is always a userland pointer.

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

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

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

Pointers are NULL not 0.
Remove obviously unnecessary iBCS2 shm stuff... we're ARM after all.

Patch from Tony Lindgren

This is an updated version of patch 2004/1 to optimize for immediate constant

Patch from Lennert Buytenhek

Hi,

gcc doesn't understand 80-bit floating point on the ARM currently,
according to the kernel's Kconfig docs, but it would seem that the
current extended double emulation code is broken for big endian
platforms.

So, this patch disables NWFPE_XP on big endian architectures, until
someone comes round and fixes it.


cheers,
Lennert

Patch from Lennert Buytenhek

Hi,

I need the patch below (against 2.6.8-rc1-ds1) to make nwfpe properly
emulate arithmetic with doubles on a big endian ARM platform.

From reading the mailing list archives and from helpful comments I've
received from people on this list, I gather that this has come up in
the past, but it appears that Russell King was never really convinced
as to why this patch is needed.  I think I understand what's going on,
and will try to explain.

On little endian ARM, the double value 1.0 looks like this when stored
in memory in FPA word ordering:
bytes: 0x00 0x00 0xf0 0x3f 0x00 0x00 0x00 0x00
u32s:  0x3ff00000 0x00000000
u64:   0x000000003ff00000

On big endian, it looks like this:
bytes: 0x3f 0xf0 0x00 0x00 0x00 0x00 0x00 0x00
u32s:  0x3ff00000 0x00000000
u64:   0x3ff0000000000000

It appears to be this way because once upon a time, somebody decided
that the sub-words of a double will use native endian word ordering
within themselves, but the two separate words will always be stored
with the most significant one first.  God knows why they did it this
way, but they did.

Anyway.  The key observation is that nwfpe internally stores double
values in the type 'float64', which is basically just a typedef for
unsigned long long.  It never accesses 'float64's on the byte level
by casting pointers around or anything like that, it just uses direct
u64 arithmetic primitives (add, shift, or, and) for float64
manipulations and that's it.

So.  For little endian platforms, 1.0 looks like:
0x00 0x00 0xf0 0x3f 0x00 0x00 0x00 0x00
But since nwfpe treats it as a u64, it wants it to look like:
0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x3f
So, that's why the current code swaps the words around when getting
doubles from userspace and putting them back (see fpa11_cpdt.c,
loadDouble and storeDouble.)

On big endian, 1.0 looks like:
0x3f 0xf0 0x00 0x00 0x00 0x00 0x00 0x00
Since nwfpe treats it as a u64, it wants it to look like:
0x3f 0xf0 0x00 0x00 0x00 0x00 0x00 0x00
Hey!  That's exactly the same.  So in this case, it shouldn't be
swapping the halves around.  However, it currently does that swapping
unconditionally, and that's why floating point emulation messes up.

This is how I understand things -- hope it makes sense to other people
too.


cheers,
Lennert

Patch from Ben Dooks

Fixes missing IRQ_TICK from RTC resources

Patch from Ben Dooks

Updated all arch/arm/mach-s3c2410/mach-XXX.c files to
register default set of devices

Added new board struct to keep this sort of info, as it
isn't possible to register platform_devices until after
the init_io functions have been called.

Patch from Ben Dooks

Added clock definition for watchdog, and fixed it so
that clocks that cannot be enabled/disabled will be
left alone.

Fixed typo in naming of clocks when registering

The following patch implements a pci_remove_bus() that can be used by
hotplug drivers for the removal of root buses.  It also defines a
release function that frees the device struct for pci_bus->bridge when a
root bus class device is unregistered.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The returned value can not be null. Yet its description suggests differently.

From: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch changes all the i2c chip drivers and documentation to use the
name "cpu0_vid" instead of "in0_ref". The name "in0_ref" was an error in
the first place as motherboard manufacturers may fail to follow the chip
manufacturer's recommendation about which "in" channel to use for VCore
monitoring.

The new name leaves room for chips able to monitor more than 1 vid
value, such as the LM93 and, to a lesser extent, the PC87360 family (all
by National Semiconductor). These chips are typically designed for
dual-CPU motherboards.

This breaks the interface (obviously) so libsensors has been updated to
support both names.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This is needed for iBook2 owners to be able to use their ADM1030
hardware monitoring chip. Successfully tested by one user.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

into kroah.com:/home/greg/linux/BK/driver-2.6

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

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Add support for a couple of BIOS ROM devices.

The patch has been committed to the MTD CVS tree and adds entries to
jedec_probe.c for AMD AM29F002T, Hyundai HY29F002T and Macronix
MX29F002T parts.

This version is slightly updated from the previous once since I
accidentally added MANUFACTURER_MACRONIX when it already existed.  I
also moved the new definitions to go along with the alphabetical by
manufacturer layout of the file. 
Signed-off-by: Ian Campbell <icampbell@arcom.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

It's being passed a global everywhere, so it may as well directly reference it.
Signed-off-by: Dave Jones <davej@redhat.com>

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

Some daemons try to set the speed to the same speed we're currently
running at. Detect that, and bail out early before we fiddle
with registers and such.
Signed-off-by: Dave Jones <davej@redhat.com>

From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>

From: Sven Traenkle

The second part adresses a problem of resetting the max cpu-freq when
unloading the driver. This didn't work for my cpu and I doubt it does
for other. There is no need to pass the computed index of the max.
multiplier in the clock_ratio[] table to longhault_table[] cause the
longhaul_setstate function works with the clock_ratio[] index.
                                                                                                          
Changing the while loop to a for loop with upper limit isn't actually
necessary as long as the driver is bug free, but thats IMHO not yet the
case, so I suggest this change in order to not loop endlessly or read
beyond the limits of the clock_ratio array.
Signed-off-by: Dave Jones <davej@redhat.com>

From: Sven Traenkle.

here's a patch that solves some issues I have with the longhaul cpufreq
driver on my epia 6000CL/Via EDEN (actually reporting as CentaurHauls,
family 6, model 7, VIA Samuel 2). The driver tries to compute the fsb speed
while it could actually use the fixed values (as it does for model == 6).
I got this change from the via forum, so no credits to me.
Signed-off-by: Dave Jones <davej@redhat.com>