linux-toradex.git/arch, branch v2.6.27.7

m68k: Fix off-by-one in m68k_setup_user_interrupt()

2008-11-20T22:54:49+00:00

commit 27123cbc264de89ce6951b1b4c84c223eb0f1702 upstream.

commit 69961c375288bdab7604e0bb1c8d22999bb8a347 ("[PATCH] m68k/Atari:
Interrupt updates") added a BUG_ON() with an incorrect upper bound
comparison, which causes an early crash on VME boards, where IRQ_USER is
8, cnt is 192 and NR_IRQS is 200.

Reported-by: Stephen N Chivers 
Tested-by: Kars de Jong 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

S390: cpu topology: fix locking

2008-11-20T22:54:49+00:00

commit 74af283102b358b0da545460d0d176f473e110f6 upstream.

cpu_coregroup_map used to grab a mutex on s390 since it was only
called from process context.
Since c7c22e4d5c1fdebfac4dba76de7d0338c2b0d832 "block: add support
for IO CPU affinity" this is not true anymore.
It now also gets called from softirq context.

To prevent possible deadlocks change this in architecture code and
use a spinlock instead of a mutex.

Cc: Jens Axboe 
Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

powerpc/mpic: Fix regression caused by change of default IRQ affinity

2008-11-20T22:54:47+00:00

commit 3c10c9c45e290022ca7d2aa1ad33a0b6ed767520 upstream.

The Freescale implementation of MPIC only allows a single CPU destination
for non-IPI interrupts.  We add a flag to the mpic_init to distinquish
these variants of MPIC.  We pull in the irq_choose_cpu from sparc64 to
select a single CPU as the destination of the interrupt.

This is to deal with the fact that the default smp affinity was
changed by commit 18404756765c713a0be4eb1082920c04822ce588 ("genirq:
Expose default irq affinity mask (take 3)") to be all CPUs.

Signed-off-by: Kumar Gala 
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

ARM: 5329/1: Feroceon: fix feroceon_l2_inv_range

2008-11-20T22:54:43+00:00

commit 72bc2b1ad62f4d2f0a51b35829093d41f55accce upstream.

Same fix as commit c7cf72dcadb: when 'start' and 'end' are less than a
cacheline apart and 'start' is unaligned we are done after cleaning and
invalidating the first cacheline.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 5300/1: fixup spitz reset during boot

2008-11-13T17:56:03+00:00

commit 69fc7eed5f56bce15b239e5110de2575a6970df4 upstream

Some machines don't have the pullup/down on their reset
pin, so configuring the reset generating pin as input makes
them reset immediately. Fix that by making reset pin direction
configurable.

This fixes the boot problem on Sharp Zaurus c3000

Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Russell King 
Signed-off-by: Pavel Machek 
Signed-off-by: Greg Kroah-Hartman

x86: don't use tsc_khz to calculate lpj if notsc is passed

2008-11-13T17:55:58+00:00

commit 70de9a97049e0ba79dc040868564408d5ce697f9 upstream

Impact: fix udelay when "notsc" boot parameter is passed

With notsc passed on commandline, tsc may not be used for
udelays, make sure that we do not use tsc_khz to calculate
the lpj value in such cases.

Reported-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Alok N Kataria 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

ARM: xsc3: fix xsc3_l2_inv_range

2008-11-13T17:55:58+00:00

commit c7cf72dcadbe39c2077b32460f86c9f8167be3be upstream

When 'start' and 'end' are less than a cacheline apart and 'start' is
unaligned we are done after cleaning and invalidating the first
cacheline.  So check for (start < end) which will not walk off into
invalid address ranges when (start > end).

This issue was caught by drivers/dma/dmatest.

2.6.27 is susceptible.

Cc: 
Cc: Haavard Skinnemoen 
Cc: Lothar Wafmann 
Cc: Lennert Buytenhek 
Cc: Eric Miao 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

x86: fix macro with bad_bios_dmi_table

2008-11-13T17:55:55+00:00

commit a8b71a2810386a5ac8f43d2095fe3355f0d8db37 upstream.

DMI tables need a blank NULL tail.

fixes the crash on Ingo's test box.

Signed-off-by: Yinghai Lu 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: fix CONFIG_X86_RESERVE_LOW_64K=y

2008-11-13T17:55:55+00:00

commit 2216d199b1430d1c0affb1498a9ebdbd9c0de439 upstream

The bad_bios_dmi_table() quirk never triggered because we do DMI setup
too late. Move it a bit earlier.

Also change the CONFIG_X86_RESERVE_LOW_64K quirk to operate on the e820
table directly instead of messing with early reservations - this handles
overlaps (which do occur in this low range of RAM) more gracefully.

Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: add X86_RESERVE_LOW_64K

2008-11-13T17:55:55+00:00

commit fc38151947477596aa27df6c4306ad6008dc6711 upstream.

This bugzilla:

  http://bugzilla.kernel.org/show_bug.cgi?id=11237

Documents a wide range of systems where the BIOS utilizes the first
64K of physical memory during suspend/resume and other hardware events.

Currently we reserve this memory on all AMI and Phoenix BIOS systems.
Life is too short to hunt subtle memory corruption problems like this,
so we try to be robust by default.

Still, allow this to be overriden: allow users who want that first 64K
of memory to be available to the kernel disable the quirk, via
CONFIG_X86_RESERVE_LOW_64K=n.

Also, allow the early reservation to overlap with other
early reservations.

Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman