[PATCH] ppc32: Improve workaround for 74xx CPUs with broken BTIC
The previous workaround didn't enable the BTIC bit on CPUs where it is
broken. However, it seems some firmwares will unconditionally set it,
so this new patch will actually _clear_ it on CPUs where it is broken.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The trackpad on recent Apple laptops tend to emmit spurrious 'right
clicks' apparently. This patch from Alex Clausen fixes it, please
apply. The trackpad cannot normally emit a right click, so just filter
those out.
Signed-off-by: Alexander Clausen <alex@skip86.com> Signed-off-by: Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Thu, 26 Aug 2004 01:13:08 +0000 (18:13 -0700)]
[PATCH] missing include of config.h in asm-alpha/page.h
That was a nasty one - missing include of config.h in a file that has
non-trivial ifdefs. With some configs it ended up with very odd conflicts
(we get included early, take the wrong branch of ifdef, then get another
file included, it pulls in config.h and picks the right branch of its
ifdef; surprise, surprise, they conflict).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Linus Torvalds [Wed, 25 Aug 2004 14:31:10 +0000 (07:31 -0700)]
Revert I2C keywest class fixup
Benh says: "Please revert that for now, I need to figure out what they
were exactly trying to do and will come up with something if it makes
sense but the patch as-is doesn't"
David Mosberger [Wed, 25 Aug 2004 11:06:16 +0000 (04:06 -0700)]
[PATCH] signal-race-fix: ia64
It looks fine to me, except that I decided to play chicken as far as the
give_sigsegv update of sa_handler is concerned.
Arun, I hope I got the ia32 emulation parts right, but you may want to
double-check.
The patch seems to work fine as far as I have tested. I'm seeing some
oddity in context-switch overhead and pipe latency as reported by LMbench,
but I suspect that's due to another change that happened somewhere between
2.6.5-rc1 and Linus' bk tree as of this morning.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andi Kleen [Wed, 25 Aug 2004 11:01:29 +0000 (04:01 -0700)]
[PATCH] signal-race-fixes: x86-64 support
Add the signal race changes to x86-64 to make it compile again.
Didn't merge the more pointless changes from i386.
Also remove the special SA_ONESHOT handling, doesn't seem to be needed
anymore.
From: Mikael Pettersson <mikpe@csd.uu.se>
The signal-race-fixes patch in 2.6.8-rc2-mm1 appears to have broken
x86-64's ia32 emulation.
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 the normal signal delivery code
does.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
Corey Minyard [Wed, 25 Aug 2004 11:00:58 +0000 (04:00 -0700)]
[PATCH] signal handling race fix
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)
[BRIDGE]: Fix oops when mangling and brouting and tcpdumping packets
The ebtables brouting chain, traversed through the call
br_should_route_hook(), can alter a packet. The redirect target
does this, f.e., to change the MAC destination.
Bart discovered this and proposed a patch; this is a revised version.
This version cleans up the handle_bridge code in net/core/dev.c as well
as getting rid of extra rcu_read_lock and only does the br_port checking
once.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@redhat.com>
[ARM PATCH] 2047/1: disable NWFPE_XP on big endian
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.
[ARM PATCH] 2046/1: fix nwfpe for double arithmetic on big-endian platforms
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.
Ben Dooks [Wed, 25 Aug 2004 18:14:27 +0000 (19:14 +0100)]
[ARM PATCH] 2043/1: S3C2410 update to registered devices
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.
John Rose [Wed, 25 Aug 2004 06:23:54 +0000 (23:23 -0700)]
[PATCH] PCI Hotplug: create pci_remove_bus()
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>
Jean Delvare [Wed, 25 Aug 2004 06:21:59 +0000 (23:21 -0700)]
[PATCH] I2C: rename in0_ref to cpu0_vid
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>
Ian Campbell [Wed, 25 Aug 2004 03:46:37 +0000 (20:46 -0700)]
[PATCH] MTD: Additional JEDEC device types
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>
Dave Jones [Tue, 24 Aug 2004 19:49:29 +0000 (20:49 +0100)]
[CPUFREQ] Work around some broken userspace daemons.
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.
Dave Jones [Tue, 24 Aug 2004 19:21:37 +0000 (20:21 +0100)]
[CPUFREQ] Fix reset-to-max-speed on unloading of longhaul driver.
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.
Dave Jones [Tue, 24 Aug 2004 19:17:48 +0000 (20:17 +0100)]
[CPUFREQ] Samuel2 can use eblcr to determine FSB.
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.
Dave Jones [Tue, 24 Aug 2004 19:08:43 +0000 (20:08 +0100)]
[CPUFREQ] Further cleanups to longhaul driver using defines.
By defining the cpu type at startup, we can make a lot of comparisons
a lot more obvious what they are meaning.
Paul Mackerras [Tue, 24 Aug 2004 16:39:21 +0000 (09:39 -0700)]
[PATCH] ppc64: better handling of H_ENTER failures
This changes the hash insertion routines to return an error instead of
calling panic() when HV refuses to insert a HPTE (the hypervisor call to
set up a hashtable PTE is H_ENTER).
The error is now propagated upstream, and either bad_page_fault() is
called (kernel mode) or a SIGBUS signal is forced (user mode). Some
other panic() cases are also turned into BUG_ON.
Overall, this should provide us with better debugging data if the
problem happens, and avoids errors from userland mapping /dev/mem and
trying to use forbidden IOs (XFree ?) to bring the whole kernel down.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Dave Jones [Tue, 24 Aug 2004 16:38:01 +0000 (17:38 +0100)]
[CPUFREQ] Powersaver also has voltage scaling abilities.
We currently don't do voltage scaling, but we can at least set things up
to prepare for when we do.
Andrew Morton [Tue, 24 Aug 2004 19:34:10 +0000 (15:34 -0400)]
[PATCH] 8139too: be sure to progress during rtl8139_rx()
From: Francois Romieu <romieu@fr.zoreil.com>
If the Rx buffer gets corrupted or the FIFO hangs in new interesting ways,
this code prevents the driver from looping in ksoftirqd context without
making any progress.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Tue, 24 Aug 2004 19:34:00 +0000 (15:34 -0400)]
[PATCH] 8139too: Rx fifo/overflow recovery
From: Francois Romieu <romieu@fr.zoreil.com>
This patch allows to update the interrupt status register after an Rx
overflow or a Rx fifo error even when the Rx buffer contains no packet.
The update must be kept in the packet processing loop to prevent an Rx
error storm. As an interesting behavior, the status of the interrupt
status register must not be read early.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Tue, 24 Aug 2004 19:33:39 +0000 (15:33 -0400)]
[PATCH] drivers/net/wan/cycx_x25.c:189: warning: conflicting types for built-in function 'log2'
From: Jesper Juhl <juhl-lkml@dif.dk>
To silence the warning in $subject, rename log2 to cycx_log2 in this file
to remove the clash, so there's no doubt that this file uses it's own
defined log2 function.
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Tue, 24 Aug 2004 19:26:50 +0000 (15:26 -0400)]
[PATCH] fix net/hamradio/dmascc with gcc 3.4
From: Adrian Bunk <bunk@fs.tum.de>
drivers/net/hamradio/dmascc.c: In function `scc_isr':
drivers/net/hamradio/dmascc.c:250: sorry, unimplemented: inlining
failed in call to 'z8530_isr': function body not available
drivers/net/hamradio/dmascc.c:969: sorry, unimplemented: called from
here
drivers/net/hamradio/dmascc.c:250: sorry, unimplemented: inlining
failed in call to 'z8530_isr': function body not available
drivers/net/hamradio/dmascc.c:978: sorry, unimplemented: called from
here
Signed-off-by: Adrian Bunk <bunk@fs.tum.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Tue, 24 Aug 2004 19:26:40 +0000 (15:26 -0400)]
[PATCH] sk98lin/skge.c doesn't compile with PROC_FS=n
From: Adrian Bunk <bunk@fs.tum.de>
drivers/net/sk98lin/skge.c: In function `skge_remove_one':
drivers/net/sk98lin/skge.c:5116: warning: implicit declaration of function `remove_proc_entry'
drivers/net/sk98lin/skge.c:5116: `pSkRootDir' undeclared (first use in this function)
drivers/net/sk98lin/skge.c:5116: (Each undeclared identifier is reported only once
drivers/net/sk98lin/skge.c:5116: for each function it appears in.)
drivers/net/sk98lin/skge.c: In function `skge_init':
drivers/net/sk98lin/skge.c:5188: `SK_Root_Dir_entry' undeclared (first use in this function)
Signed-off-by: Adrian Bunk <bunk@fs.tum.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Tue, 24 Aug 2004 19:26:28 +0000 (15:26 -0400)]
[PATCH] via-velocity: more inetaddr_notifier fix
From: Francois Romieu <romieu@fr.zoreil.com>
There is no guarantee that the event which gets passed is associated to a
via-velocity device, thus preventing to dereference dev->priv as if it
always was a struct velocity_info *. The via-velocity devices are kept in
a module private list for comparison.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Tue, 24 Aug 2004 19:26:18 +0000 (15:26 -0400)]
[PATCH] ixgb_main.c: fix inline compile errors
From: Adrian Bunk <bunk@fs.tum.de>
drivers/net/ixgb/ixgb_main.c: In function `ixgb_up':
drivers/net/ixgb/ixgb_main.c:86: sorry, unimplemented: inlining failed
in call to 'ixgb_irq_enable': function body not available
drivers/net/ixgb/ixgb_main.c:234: sorry, unimplemented: called from here
Signed-off-by: Adrian Bunk <bunk@fs.tum.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Tue, 24 Aug 2004 19:26:07 +0000 (15:26 -0400)]
[PATCH] net/tulip/dmfe.c: gcc-3.5 fixes
From: Adrian Bunk <bunk@fs.tum.de>
CC drivers/net/tulip/dmfe.o
drivers/net/tulip/dmfe.c: In function `dmfe_rx_packet':
drivers/net/tulip/dmfe.c:323: sorry, unimplemented: inlining failed in
call to 'cal_CRC': function body not available
drivers/net/tulip/dmfe.c:936: sorry, unimplemented: called from here
make[3]: *** [drivers/net/tulip/dmfe.o] Error 1
Signed-off-by: Adrian Bunk <bunk@fs.tum.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Tue, 24 Aug 2004 19:25:57 +0000 (15:25 -0400)]
[PATCH] net/rrunner.c: gcc-3.5 fixes
From: Adrian Bunk <bunk@fs.tum.de>
CC drivers/net/rrunner.o
drivers/net/rrunner.c: In function `rr_timer':
drivers/net/rrunner.h:846: sorry, unimplemented: inlining failed in call
to 'rr_raz_tx': function body not available
drivers/net/rrunner.c:1155: sorry, unimplemented: called from here
drivers/net/rrunner.h:847: sorry, unimplemented: inlining failed in call
to 'rr_raz_rx': function body not available
drivers/net/rrunner.c:1156: sorry, unimplemented: called from here
make[2]: *** [drivers/net/rrunner.o] Error 1
Signed-off-by: Adrian Bunk <bunk@fs.tum.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Tue, 24 Aug 2004 19:25:47 +0000 (15:25 -0400)]
[PATCH] net/hamachi.c: gcc-3.5 build fixes
From: Adrian Bunk <bunk@fs.tum.de>
CC drivers/net/hamachi.o
drivers/net/hamachi.c: In function `hamachi_interrupt':
drivers/net/hamachi.c:562: sorry, unimplemented: inlining failed in call
to 'hamachi_rx': function body not available
drivers/net/hamachi.c:1402: sorry, unimplemented: called from here
make[2]: *** [drivers/net/hamachi.o] Error 1
Signed-off-by: Adrian Bunk <bunk@fs.tum.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
CC drivers/net/smc9194.o
drivers/net/smc9194.c: In function `smc_interrupt':
drivers/net/smc9194.c:278: sorry, unimplemented: inlining failed in call
to 'smc_rcv': function body not available
drivers/net/smc9194.c:1254: sorry, unimplemented: called from here
drivers/net/smc9194.c:283: sorry, unimplemented: inlining failed in call
to 'smc_tx': function body not available
drivers/net/smc9194.c:1258: sorry, unimplemented: called from here
make[2]: *** [drivers/net/smc9194.o] Error 1
Signed-off-by: Adrian Bunk <bunk@fs.tum.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Tue, 24 Aug 2004 19:25:15 +0000 (15:25 -0400)]
[PATCH] e1000 build fix
drivers/net/e1000/e1000_main.c: In function `e1000_up':
drivers/net/e1000/e1000_main.c:136: sorry, unimplemented: inlining failed
in call to 'e1000_irq_enable': function body not available
drivers/net/e1000/e1000_main.c:274: sorry, unimplemented: called from here
Andrew Morton [Tue, 24 Aug 2004 19:25:05 +0000 (15:25 -0400)]
[PATCH] sk98lin procfs fix
From: Christoph Hellwig <hch@infradead.org>
sk98line tries to register a procfile with the interfacename of the struct
net_device. The patch below (ontop of the previous one) makes it work
unless you change the interface name manually, but as Linux explicitly
allows that the interface is fundamentally broken and probably should just
go away.
projects / linux / log