Holger Freyther [Sun, 28 Nov 2004 16:07:53 +0000 (16:07 +0000)]
[ARM PATCH] 2280/1: [PATCH] SIMpad: Change maintainer to me
Patch from Holger Hans Peter Freyther
Line numbers could depend on 2279/1
Change the maintainer of the SIMpad board to me. This change was discussed on the simpad linux mailinglist and was supported by the former maintainer of SIMpad. I'll subscribe and introduce myself shortly on the arm linux mailinglist and ask for SIMpad not to be removed.
Signed-off-by: Holger Hans Peter Freyther Signed-off-by: Russell King
Holger Freyther [Sun, 28 Nov 2004 16:02:29 +0000 (16:02 +0000)]
[ARM PATCH] 2279/1: [PATCH] SIMpad: Add a mq200 device to the platform bus
Patch from Holger Hans Peter Freyther
The SIMpad uses the MediaQ 200 framebuffer device. There is no driver in the vanilla kernel for that device. But adding the device to the platform bus makes it possible to just drop the mq200 driver into the kernel and the display will work.
Please consider applying the patch.
Signed-off-by: Holger Hans Peter Freyther Signed-off-by: Russell King
Alexander Viro [Sun, 28 Nov 2004 07:08:13 +0000 (23:08 -0800)]
[PATCH] iomem annotations and fixes + isa_-ectomy in msnd
* switched to ioremap() + normal operations
* split msnd_fifo_write() (and msnd_fifo_read()) into iomem and normal
versions (original was even worse - it used to do __user and __iomem
versions in the same code and in atomic context; when that bogosity
got fixed, the difference between these cases (now normal memory and
iomem) had been lost).
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Sun, 28 Nov 2004 07:07:22 +0000 (23:07 -0800)]
[PATCH] seagate iomem annotations, cleanup and isa_-ectomy
* switched to ioremap()
* switched to normal iomem operations
* killed a bunch of phys_to_virt()
* killed open-coded (and inferior) instances of memcpy_toio()/memcpy_fromio().
* fixed a dumb typo introduced in "kill off isa_check_signature()"
patch (sorry - missed the fact that it was not covered by
allmodconfig and didn't verify until after sending the patch in
question ;-/).
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Sat, 27 Nov 2004 06:48:17 +0000 (22:48 -0800)]
[PATCH] tpam annotations and cleanups
annotated, sanitized casts between pointers and numbers, switched the
functions that took offsets in card memory to unsigned long (from the
void *, which was absolutely wrong and lead to bogus casts from hell all
over the place).
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Sat, 27 Nov 2004 06:47:26 +0000 (22:47 -0800)]
[PATCH] more sparc64 io.h annotations
Prototypes annotated the same way they are on other platforms. I'm not
too fond of readb() taking const volatile void * (sic), but AFAICS
that's the only way to tell cc(1) that both volatile and const pointers
are acceptable here ;-/
memcpy_toio/memcpy_fromio/memset_io made void - same as they are
elsewhere. And no, nobody had been insane enough to use the return
values...
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
CLOCK_TICK_RATE is 12MHz on at least 2 s3c2410 based
machines, or close to it. Although this doesn't seem
to have any effect on loops_per_jiffie, it is best
to try and be accurate.
Signed-off-by: Ben Dooks Signed-off-by: Russell King
Deepak Saxena [Fri, 26 Nov 2004 20:52:31 +0000 (20:52 +0000)]
[ARM PATCH] 2261/1: Cleanup use of ixp_reg_write in arch/arm/mach-ixp2000
Patch from Lennert Buytenhek
Several files in this directory directly dereference pointers
to on-chip I/O instead of using ixp_reg_write, making them
susceptible to IXP2400 erratum #66. This changset fixes those.
We do not touch any files that will only be built for IXP2800
systems as the 2800 does not have this issue.
Signed-off-by: Lennert Buytenhek Signed-off-by: Deepak Saxena Signed-off-by: Russell King
Deepak Saxena [Fri, 26 Nov 2004 20:47:14 +0000 (20:47 +0000)]
[ARM PATCH] 2260/1: Rename IXP2000_IRQ_SWI to reduce user confusion
Patch from Lennert Buytenhek
IXP2000 interrupt source zero is a software-generated interrupt source,
but it is not an SWI in the ARM sense of the word. Rename the interrupt
source to reduce any confusion.
Signed-off-by: Lennert Buytenhek Signed-off-by: Deepak Saxena Signed-off-by: Russell King
Deepak Saxena [Fri, 26 Nov 2004 20:42:00 +0000 (20:42 +0000)]
[ARM PATCH] 2259/1: Rip out ixp2000 IRQ_ERR_STATUS demultiplexing
Patch from Lennert Buytenhek
There are thirteen different IRQs chained off IRQ_ERR_STATUS, one for
each possible error class that the IXP can signal an interrupt for, but
there are no in-tree users of these interrupts, and it doesn't make much
sense to treat them as separate interrupts if we can just have one
handler checking each of the thirteen errors in one go instead.
Besides that, the error interrupt handling can't even have been working
properly in the first place as the chained handler was testing the wrong
bits in the IRQ_ERR_STATUS register.
So this patch rips it all out.
Signed-off-by: Lennert Buytenhek Signed-off-by: Deepak Saxena Signed-off-by: Russell King
Deepak Saxena [Fri, 26 Nov 2004 20:30:27 +0000 (20:30 +0000)]
[ARM PATCH] 2255/1: Add IXDPG425 platform support
Patch from Deepak Saxena
New IXP425 based platform from Intel. This machine is similar to
an ADI Coyote except for the addition of an on-board NEC ECHI
controller. Patch also fixes issue with board setup for Coyote
(and IXDPG425) that would cause the MTD driver to fail.
Signed-off-by: Deepak Saxena Signed-off-by: Russell King
Ingo Molnar [Fri, 26 Nov 2004 01:08:19 +0000 (17:08 -0800)]
[PATCH] floppy boot-time detection fix
When the FDC hardware is initialized, it sometimes generates a floppy
interrupt right away - without being told to. This interrupt can hit
the detection code that executes right after the initialization code, in
particular it can get intermixed with user_reset_fdc() that the
detection code uses. The fd driver is fundamentally single-threaded
when it comes to handling events: an unexpected irq that arrives in the
wrong moment can confuse the reset_fdc() code, which, with softirq and
hardirq threading on, executes in keventd.
In the stock kernel this stale irq doesnt seem to hit the detection code
in the wrong moment, but i think under certain circumstances it may
still happen. One of the typical incarnations of the race was the
following message:
and googling for "reset set in interrupt, calling" does turn up a fair
number of bootlogs (most of them 2.4 ones) that show such a detection
failure, so i think upstream wants to have the fix too.
the fix is simple: delay a bit after initialization, to make sure the
stale irq does not interfere with the detection code. It will be safely
ignored, since do_floppy is still NULL. It might look sloppy that i went
for a delay, but delay i think it is better than waiting for the irq to
occur, because i dont think there's a guarantee that fdc initialization
triggers an interrupt, so waiting for it could hang the boot process. A
delay OTOH is totally harmless.
The attached patch implements this fix, which resolves the detection
problem on my testbox.
here's again how a failure looks like:
Floppy drive(s): fd0 is 1.44M
reset set in interrupt, calling c0258400
floppy0: no floppy controllers found
and this is how it works with the fix:
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
There is a stupid error in cfq-iosched that spews a warning on
(typically) SMP systems because cfqq->allocated[rw] goes below zero. The
error is that the increment on alloc happens outside of the queue lock.
Paul Mackerras [Fri, 26 Nov 2004 00:45:43 +0000 (16:45 -0800)]
[PATCH] ppc64: fix hang on legacy iSeries
Recently we have uncovered a bug in the kernel exception exit path
which can cause iSeries machines to hang with interrupts disabled,
typically when unloading a module. This patch fixes the bug and
should go in 2.6.10. Here is the detailed explanation:
There are a couple of places in the exception exit path in entry.S
where we disable interrupts and then later reenable them. We
hard-disable interrupts even on legacy iSeries (rather than
soft-disabling them) because the final part of the exception exit path
needs interrupts hard-disabled (even on legacy iSeries), because
otherwise an incoming interrupt could trash SRR0 and SRR1 and cause us
to lose state.
The intention was that each path that hard-disabled interrupts would
hard-enable them again, either explicitly or by executing an rfid
instruction (return from interrupt, doubleword). However there was
one path where we didn't correctly hard-enable interrupts. This meant
we could end up calling schedule() with interrupts hard-disabled and
then switch to the stopmachine thread (used in removing a module),
which spins polling a variable until another cpu changes it. Since
local_irq_enable() etc. on legacy iSeries only soft-enable interrupts,
we got into the stopmachine thread with interrupts hard-disabled, and
the machine hung at that point.
This patch fixes it by making sure that when we go to re-enable
interrupts, the MSR value we are loading up actually does have the
MSR.EE (external interrupt enable) bit set. Stephen Rothwell has
verified that this actually does fix the bug on iSeries. The bug
also potentially exists on pSeries (and this patch fixes it), but
there it doesn't really matter, because schedule() will enable
interrupts (and on pSeries that means hard-enabling them), and because
the hypervisor doesn't mind you having interrupts hard-disabled for
extended periods on pSeries. Note that all these comments about
pSeries also apply to POWER5 iSeries (i5) machines.
While I was there I noticed that we were jumping to ret_from_except
after calling do_IRQ on iSeries, rather than ret_from_except_lite,
meaning that we will restore registers 14-31 twice, unnecessarily. I
changed it to jump to ret_from_except_lite instead, and Stephen
checked that this change doesn't cause any breakage.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Zou Nanhai [Thu, 25 Nov 2004 08:00:28 +0000 (00:00 -0800)]
[PATCH] ia64/x86_64/s390 overlapping vma fix
IA64 is also vulnerable to the huge-vma-in-executable bug in 64 bit elf
support, it just insert a vma of zero page without checking overlap, so user
can construct a elf with section begin from 0x0 to trigger this BUGON().
However, I think it's safe to check overlap before we actually insert a vma
into vma list. And I also feel check vma overlap everywhere is unnecessary,
because invert_vm_struct will check it again, so the check is duplicated.
It's better to have invert_vm_struct return a value then let caller check if
it successes. Here is a patch against 2.6.10.rc2-mm3 I have tested it on
i386, x86_64 and ia64 machines.
Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Zou Nan hai <Nanhai.zou@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The ppc32 PowerMac cpufreq code, when using the PMU to switch the
frequency, would eventually lose interrupts. The solution is to raise the
CPU priority at the controller level. It's also unnecessary to call the
full PIC suspend/resume code in this case as the IO chip isn't reset,
unlike the sleep code.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Tom Rini [Thu, 25 Nov 2004 07:59:48 +0000 (23:59 -0800)]
[PATCH] ppc32: Have the 8260 board-hook happen a bit later
Borut Lukic <borutlukic@email.si> brought to my attention that in
platform_init() on 8260 the board hook was being called too early to allow for
overrides (e.g. different memory sizings functions or rtc, or anything else).
This moves the call to the end of platform_init() and I suspect fixes some
unnoticed yet bugs in a number of 8260 platforms.
Signed-off-by: Tom Rini <trini@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Olof Johansson [Thu, 25 Nov 2004 07:59:21 +0000 (23:59 -0800)]
[PATCH] ppc64: Make early processor spinup based on physical ids
This changes the early CPU spinup code to be based on physical CPU ID
instead of logical. This will make it possible to kexec off of a
different cpu than 0, for example after it's been hot-unplugged.
The booted cpu will still be mapped as logical cpu 0, since there's various
stuff in the early boot that assumes logical boot cpuid is 0.
Also, it expands the kexec boot param structure to allow the booted physical
cpuid to be passed in. This includes bumping the version number to 2 for
backwards compat.
Signed-off-by: Olof Johansson <olof@austin.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Anton Blanchard [Thu, 25 Nov 2004 07:59:08 +0000 (23:59 -0800)]
[PATCH] ppc64: linux,tce* changes
Remove linux,has-tce-table since we can just look for linux,tce-base and
linux,tce-size. Make linux,tce-base store real addresses instead of virtual
ones, the wrapper may not know the translation the kernel will use.
Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andrew Morton [Thu, 25 Nov 2004 07:58:26 +0000 (23:58 -0800)]
[PATCH] dont deprecate MODULE_PARM
Let's revert this for now so all those warnings do not soil our 2.6.10
release. We'll get Rusty's kernel-wide-sweep fixup patches in for 2.6.11, and
then we can put this warning back.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paul Mackerras [Thu, 25 Nov 2004 07:58:00 +0000 (23:58 -0800)]
[PATCH] ppc64: fix compilation with recent toolchains
The ppc64 toolchains don't create dot symbols (i.e. a globally
visible ".foo" symbol for the text of function foo) any more.
This breaks the kernel compile because we refer to function text
addresses in the system call table.
Fortunately there is an option, -mcall-aixdesc, which restores the
previous behaviour, and even more fortunately, old ppc64 toolchains
understand the option as well as new ones.
This patch adds -mcall-aixdesc to CFLAGS in arch/ppc64/Makefile.
Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Don Fry [Wed, 24 Nov 2004 10:23:30 +0000 (05:23 -0500)]
[PATCH] pcnet32: added pci_disable_device
This patch adds pci_disable_device in the appropriate places to
eliminate the following message when removing the module.
pcnet32 0000:00:05.0: Device was removed without properly calling pci_disable_device(). This may need fixing.
pcnet32 0000:02:05.0: Device was removed without properly calling pci_disable_device(). This may need fixing.
Tested ia32.
signed-off-by: Don Fry <brazilnut@us.ibm.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Andrew Morton [Wed, 24 Nov 2004 09:58:41 +0000 (04:58 -0500)]
[PATCH] make ibmveth link always up
From: Santiago Leon <santil@us.ibm.com>
The attached patch makes the ibmveth driver indicate that its link is
always up rather than always down, thus allowing the userspace side of
booting to configure the network interface correctly.
Signed-Off-By: Santiago Leon <santil@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Andrew Morton [Wed, 24 Nov 2004 09:58:29 +0000 (04:58 -0500)]
[PATCH] M68k HP Lance Ethernet: Fix leaks on probe/removal
From: Geert Uytterhoeven <geert@linux-m68k.org>
HP Lance Ethernet: There's tons of leaks in the hplcance probing code, and it
doesn't release the memory region on removal either (from Christoph Hellwig)
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Andrew Morton [Wed, 24 Nov 2004 09:58:03 +0000 (04:58 -0500)]
[PATCH] tulip: make tulip_stop_rxtx() wait for DMA to fully stop
From: "John W. Linville" <linville@tuxdriver.com>
tulip_stop_rxtx() doesn't wait for DMA to fully stop like the function
call name implies.
This was submitted through my employer -- I am not the original author of this
patch. However, I passed it by Jeff Garizk and he expressed interest in
having it upstream.
Signed-off-by: Grant Grundler <iod00d@hp.com> Acked-by: Charlie Brett <charlie.brett@hp.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Andrew Morton [Wed, 24 Nov 2004 09:53:50 +0000 (04:53 -0500)]
[PATCH] e100: early reset fix
Gents, what do we think of the below fix?
Thanks.
My IBM A21P laptop is getting an IRQ storm at boot.
IRQ #11 is shared between USB and e100, and USB is getting in there first.
Consequently, when e100 initialises the hardware, that interrupt line is ready
to go. As soon as e100.c runs pci_set_master(), the interrupt hits the CPU.
But of course the e100 driver isn't ready to handle the interrupt yet, so the
system disables IRQ #11.
This only happens on warm boots (/sbin/reboot). Things work OK from power-on.
So I assume that the BIOS is failing to fully reset the NIC and that some
sort of interrupt is internally pending.
The patch rearranges e100_probe() so that we issue e100_hw_reset() prior to
running pci_set_master(), and fixes the problem.
Note that e100_probe() is now running e100_hw_reset() twice - I didn't remove
the later call for general paranoia reasons.
eepro100.c has the same lockup, and needs a similar fix.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
[ATM]: Handle register_netdevice_notifier() errors in mpc.c
Signed-off-by: walter harms <wharms@bfs.de> Signed-off-by: Maximilian Attems <janitor@sternwelten.at> Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: walter harms <wharms@bfs.de> Signed-off-by: Maximilian Attems <janitor@sternwelten.at> Signed-off-by: David S. Miller <davem@davemloft.net>
Jesper Juhl [Tue, 23 Nov 2004 11:40:52 +0000 (03:40 -0800)]
[PATCH] remove errornous semicolon in arch/i386/kernel/traps.c::do_general_protection
Building with gcc -W revealed this warning:
arch/i386/kernel/traps.c: In function `do_general_protection':
arch/i386/kernel/traps.c:506: warning: empty body in an if-statement
upon inspecting the code I see what looks like a mistakenly placed ";"
Patrick McHardy [Tue, 23 Nov 2004 10:21:09 +0000 (02:21 -0800)]
[XFRM]: Fix endless loop in xfrm_policy_insert
The patch 'Fix policy update bug when increasing
priority of last policy' broke this, when a policy
with lower priority than an existing policy is inserted
xfrm_policy_insert loops forever.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / history.git / log