linux-stable.git/arch/arm, branch v3.2.9

ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found

2012-03-01T00:31:13+00:00

commit d980e0f8d858c6963d676013e976ff00ab7acb2b upstream.

When the PMIC is not found, voltdm->pmic will be NULL.  vp.c's
initialization function tries to dereferences this, which causes an
oops:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (3.3.0-rc2+ #204)
PC is at omap_vp_init+0x5c/0x15c
LR is at omap_vp_init+0x58/0x15c
pc : []    lr : []    psr: 60000013
sp : c181ff30  ip : c181ff68  fp : c181ff64
r10: c0407808  r9 : c040786c  r8 : c0407814
r7 : c0026868  r6 : c00264fc  r5 : c040ad6c  r4 : 00000000
r3 : 00000040  r2 : 000032c8  r1 : 0000fa00  r0 : 000032c8
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 80004019  DAC: 00000015
Process swapper (pid: 1, stack limit = 0xc181e2e8)
Stack: (0xc181ff30 to 0xc1820000)
ff20:                                     c0381d00 c02e9c6d c0383582 c040786c
ff40: c040ad6c c00264fc c0026868 c0407814 00000000 c03d9de4 c181ff8c c181ff68
ff60: c03db448 c03db830 c02e982c c03fdfb8 c03fe004 c0039988 00000013 00000000
ff80: c181ff9c c181ff90 c03d9df8 c03db390 c181ffdc c181ffa0 c0008798 c03d9df0
ffa0: c181ffc4 c181ffb0 c0055a44 c0187050 c0039988 c03fdfb8 c03fe004 c0039988
ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03d1284 c0008708
ffe0: 00000000 c03d1208 00000000 c181fff8 c0039988 c03d1214 1077ce40 01f7ee08
Backtrace:
[] (omap_vp_init+0x0/0x15c) from [] (omap_voltage_late_init+0xc4/0xfc)
[] (omap_voltage_late_init+0x0/0xfc) from [] (omap2_common_pm_late_init+0x14/0x54)
 r8:00000000 r7:00000013 r6:c0039988 r5:c03fe004 r4:c03fdfb8
[] (omap2_common_pm_late_init+0x0/0x54) from [] (do_one_initcall+0x9c/0x164)
[] (do_one_initcall+0x0/0x164) from [] (kernel_init+0x7c/0x120)
[] (kernel_init+0x0/0x120) from [] (do_exit+0x0/0x2cc)
 r5:c03d1208 r4:00000000
Code: e5ca300b e5900034 ebf69027 e5994024 (e5941000)
---[ end trace aed617dddaf32c3d ]---
Kernel panic - not syncing: Attempted to kill init!

Signed-off-by: Russell King 
Cc: Igor Grinberg 
Signed-off-by: Greg Kroah-Hartman

ARM: 7325/1: fix v7 boot with lockdep enabled

2012-03-01T00:30:57+00:00

commit 8e43a905dd574f54c5715d978318290ceafbe275 upstream.

Bootup with lockdep enabled has been broken on v7 since b46c0f74657d
("ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR").

This is because v7_setup (which is called very early during boot) calls
v7_flush_dcache_all, and the save_and_disable_irqs added by that patch
ends up attempting to call into lockdep C code (trace_hardirqs_off())
when we are in no position to execute it (no stack, MMU off).

Fix this by using a notrace variant of save_and_disable_irqs.  The code
already uses the notrace variant of restore_irqs.

Reviewed-by: Nicolas Pitre 
Acked-by: Stephen Boyd 
Cc: Catalin Marinas 
Signed-off-by: Rabin Vincent 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR

2012-03-01T00:30:56+00:00

commit b46c0f74657d1fe1c1b0c1452631cc38a9e6987f upstream.

armv7's flush_cache_all() flushes caches via set/way. To
determine the cache attributes (line size, number of sets,
etc.) the assembly first writes the CSSELR register to select a
cache level and then reads the CCSIDR register. The CSSELR register
is banked per-cpu and is used to determine which cache level CCSIDR
reads. If the task is migrated between when the CSSELR is written and
the CCSIDR is read the CCSIDR value may be for an unexpected cache
level (for example L1 instead of L2) and incorrect cache flushing
could occur.

Disable interrupts across the write and read so that the correct
cache attributes are read and used for the cache flushing
routine. We disable interrupts instead of disabling preemption
because the critical section is only 3 instructions and we want
to call v7_dcache_flush_all from __v7_setup which doesn't have a
full kernel stack with a struct thread_info.

This fixes a problem we see in scm_call() when flush_cache_all()
is called from preemptible context and sometimes the L2 cache is
not properly flushed out.

Signed-off-by: Stephen Boyd 
Acked-by: Catalin Marinas 
Reviewed-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7326/2: PL330: fix null pointer dereference in pl330_chan_ctrl()

2012-03-01T00:30:53+00:00

commit 46e33c606af8e0caeeca374103189663d877c0d6 upstream.

This fixes the thrd->req_running field being accessed before thrd
is checked for null. The error was introduced in

   abb959f: ARM: 7237/1: PL330: Fix driver freeze

Reference: <1326458191-23492-1-git-send-email-mans.rullgard@linaro.org>

Signed-off-by: Mans Rullgard 
Acked-by: Javi Merino 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: at91: USB AT91 gadget registration for module

2012-03-01T00:30:49+00:00

commit e8c9dc93e27d891636defbc269f182a83e6abba8 upstream.

Registration of at91_udc as a module will enable SoC
related code.

Fix following an idea from Karel Znamenacek.

Signed-off-by: Nicolas Ferre 
Acked-by: Karel Znamenacek 
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 
Signed-off-by: Greg Kroah-Hartman

ARM: OMAP2+: GPMC: fix device size setup

2012-02-13T19:16:52+00:00

commit 8ef5d844cc3a644ea6f7665932a4307e9fad01fa upstream.

following statement can only change device size from 8-bit(0) to 16-bit(1),
but not vice versa:

regval |= GPMC_CONFIG1_DEVICESIZE(wval);

so as this field has 1 reserved bit, that could be used in future,
just clear both bits and then OR with the desired value

Signed-off-by: Yegor Yefremov 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers

2012-02-13T19:16:52+00:00

commit 8130b9d7b9d858aa04ce67805e8951e3cb6e9b2f upstream.

If we are context switched whilst copying into a thread's
vfp_hard_struct then the partial copy may be corrupted by the VFP
context switching code (see "ARM: vfp: flush thread hwstate before
restoring context from sigframe").

This patch updates the ptrace VFP set code so that the thread state is
flushed before the copy, therefore disabling VFP and preventing
corruption from occurring.

Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7307/1: vfp: fix ptrace regset modification race

2012-02-13T19:16:52+00:00

commit 247f4993a5974e6759606c4d380748eecfd273ff upstream.

In a preemptible kernel, vfp_set() can be preempted, causing the
hardware VFP context to be switched while the thread vfp state is
being read and modified.  This leads to a race condition which can
cause the thread vfp state to become corrupted if lazy VFP context
save occurs due to preemption in between the time thread->vfpstate
is read and the time the modified state is written back.

This may occur if preemption occurs during the execution of a
ptrace() call which modifies the VFP register state of a thread.
Such instances should be very rare in most realistic scenarios --
none has been reported, so far as I am aware.  Only uniprocessor
systems should be affected, since VFP context save is not currently
lazy in SMP kernels.

The problem was introduced by my earlier patch migrating to use
regsets to implement ptrace.

This patch does a vfp_sync_hwstate() before reading
thread->vfpstate, to make sure that the thread's VFP state is not
live in the hardware registers while the registers are modified.

Thanks to Will Deacon for spotting this.

Signed-off-by: Dave Martin 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7306/1: vfp: flush thread hwstate before restoring context from sigframe

2012-02-13T19:16:52+00:00

commit 2af276dfb1722e97b190bd2e646b079a2aa674db upstream.

Following execution of a signal handler, we currently restore the VFP
context from the ucontext in the signal frame. This involves copying
from the user stack into the current thread's vfp_hard_struct and then
flushing the new data out to the hardware registers.

This is problematic when using a preemptible kernel because we could be
context switched whilst updating the vfp_hard_struct. If the current
thread has made use of VFP since the last context switch, the VFP
notifier will copy from the hardware registers into the vfp_hard_struct,
overwriting any data that had been partially copied by the signal code.

Disabling preemption across copy_from_user calls is a terrible idea, so
instead we move the VFP thread flush *before* we update the
vfp_hard_struct. Since the flushing is performed lazily, this has the
effect of disabling VFP and clearing the CPU's VFP state pointer,
therefore preventing the thread from being updated with stale data on
the next context switch.

Tested-by: Peter Maydell 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

mach-ux500: no MMC_CAP_SD_HIGHSPEED on Snowball

2012-02-03T17:22:27+00:00

commit 2ab1159e80e8f416071e9f51e4f77b9173948296 upstream.

MMC_CAP_SD_HIGHSPEED is not supported on Snowball board resulting on
initialization errors.

Signed-off-by: Mathieu Poirier 
Signed-off-by: Fredrik Soderstedt 
Signed-off-by: Philippe Langlais 
Signed-off-by: Linus Walleij