linux-toradex.git/arch, branch v3.7.3

KVM: PPC: 44x: fix DCR read/write

2013-01-17T16:46:47+00:00

commit e43a028752fed049e4bd94ef895542f96d79fa74 upstream.

When remembering the direction of a DCR transaction, we should write
to the same variable that we interpret on later when doing vcpu_run
again.

Signed-off-by: Alexander Graf 
Signed-off-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

Revert "MIPS: Optimise TLB handlers for MIPS32/64 R2 cores."

2013-01-17T16:46:43+00:00

commit 9120963578320532dfb3a9a7947e8d05b39900b5 upstream.

This reverts commit ff401e52100dcdc85e572d1ad376d3307b3fe28e.

This breaks on MIPS64 R2 cores such as Broadcom's.

Signed-off-by: Jayachandran C 
Signed-off-by: Greg Kroah-Hartman

ALSA: pxa27x: fix ac97 warm reset

2013-01-17T16:46:26+00:00

commit 3b4bc7bccc7857274705b05cf81a0c72cfd0b0dd upstream.

This patch fixes some code that implements a work-around to a hardware bug in
the ac97 controller on the pxa27x.  A bug in the controller's warm reset
functionality requires that the mfp used by the controller as the AC97_nRESET
line be temporarily reconfigured as a generic output gpio (AF0) and manually
held high for the duration of the warm reset cycle.  This is what was done in
the original code, but it was broken long ago by commit fb1bf8cd
    ([ARM] pxa: introduce processor specific pxa27x_assert_ac97reset())
which changed the mfp to a GPIO input instead of a high output.

The fix requires the ac97 controller to obtain the gpio via gpio_request_one(),
with arguments that configure the gpio as an output initially driven high.

Tested on a palm treo 680 machine.  Reportedly, this broken code only prevents a
warm reset on hardware that lacks a pull-up on the line, which appears to be the
case for me.

Signed-off-by: Mike Dunn 
Signed-off-by: Igor Grinberg 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

OMAP: board-files: fix i2c_bus for tfp410

2013-01-17T16:46:08+00:00

commit ca2e16faa7378878c1522a7c1b6c38211de3331d upstream.

The i2c handling in tfp410 driver, which handles converting parallel RGB
to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af
(OMAPDSS: TFP410: pdata rewrite). The patch changed what value the
driver considers as invalid/undefined.  Before the patch, 0 was the
invalid value, but as 0 is a valid bus number, the patch changed this to
-1.

However, the fact was missed that many board files do not define the bus
number at all, thus it's left to 0. This causes the driver to fail to
get the i2c bus, exiting from the driver's probe with an error, meaning
that the DVI output does not work for those boards.

This patch fixes the issue by changing the i2c_bus number field in the
driver's platform data from u16 to int, and setting the bus number to -1
in the board files for the boards that did not define the bus. The
exception is devkit8000, for which the bus is set to 1, which is the
correct bus for that board.

The bug exists in v3.5+ kernels.

Signed-off-by: Tomi Valkeinen 
Reported-by: Thomas Weber 
Cc: Thomas Weber 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

MIPS: Fix poweroff failure when HOTPLUG_CPU configured.

2013-01-17T16:45:54+00:00

commit 8add1ecb81f541ef2fcb0b85a5470ad9ecfb4a84 upstream.

When poweroff machine, kernel_power_off() call disable_nonboot_cpus().
And if we have HOTPLUG_CPU configured, disable_nonboot_cpus() is not an
empty function but attempt to actually disable the nonboot cpus. Since
system state is SYSTEM_POWER_OFF, play_dead() won't be called and thus
disable_nonboot_cpus() hangs. Therefore, we make this patch to avoid
poweroff failure.

Signed-off-by: Huacai Chen 
Signed-off-by: Hongliang Tao 
Signed-off-by: Hua Yan 
Cc: Yong Zhang 
Cc: Fuxin Zhang 
Cc: Zhangjin Wu 
Patchwork: https://patchwork.linux-mips.org/patch/4211/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

KVM: PPC: e500: fix allocation size error on g2h_tlb1_map

2013-01-17T16:45:46+00:00

commit e400e72f250d2567e89c9bafb47ab91e8d9a15a2 upstream.

We were only allocating half the bytes we need, which was made more
obvious by a recent fix to the memset in  clear_tlb1_bitmap().

Signed-off-by: Scott Wood 
Signed-off-by: Alexander Graf 
Signed-off-by: Greg Kroah-Hartman

powerpc: Add missing NULL terminator to avoid boot panic on PPC40x

2013-01-17T16:45:45+00:00

commit e6449c9b2d90c1bd9a5985bf05ddebfd1631cd6b upstream.

The missing NULL terminator can cause a panic on
PPC405 boards during boot:

  Linux/PowerPC load: console=ttyS0,115200 root=/dev/mtdblock1 rootfstype=squashfs,jffs2 noinitrd init=/etc/preinit
  Finalizing device tree... flat tree at 0x6a5160
  bootconsole [udbg0] enabled
  Page fault in user mode with in_atomic() = 1 mm = (null)
  NIP = c0275f50  MSR = fffffffe
  Oops: Weird page fault, sig: 11 [#1]
  PowerPC 40x Platform
  Modules linked in:
  NIP: c0275f50 LR: c0275f60 CTR: c0280000
  REGS: c0275eb0 TRAP: 636f7265   Not tainted  (3.7.1)
  MSR: fffffffe  CR: c06a6190  XER: 00000001
  TASK = c02662a8[0] 'swapper' THREAD: c0274000
  GPR00: c0275ec0 c000c658 c027c4bf 00000000 c0275ee0 c000a0ec c020a1a8 c020a1f0
  GPR08: c020f631 c020f404 c025f078 c025f080 c0275f10
   Call Trace:
   ---[ end trace 31fd0ba7d8756001 ]---

  Kernel panic - not syncing: Attempted to kill the idle task!

The panic happens since commit 9597abe00c1bab2aedce6b49866bf6d1e81c9eed
(sections: fix section conflicts in arch/powerpc), however the root
cause of this is that the NULL terminator were not added in commit
a4f740cf33f7f6c164bbde3c0cdbcc77b0c4997c (of/flattree: Add of_flat_dt_match()
helper function).

Signed-off-by: Gabor Juhos 
Cc: Grant Likely 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc/vdso: Remove redundant locking in update_vsyscall_tz()

2013-01-17T16:45:45+00:00

commit ce73ec6db47af84d1466402781ae0872a9e7873c upstream.

The locking in update_vsyscall_tz() is not only unnecessary because the vdso
code copies the data unproteced in __kernel_gettimeofday() but also
introduces a hard to reproduce race condition between update_vsyscall()
and update_vsyscall_tz(), which causes user space process to loop
forever in vdso code.

The following patch removes the locking from update_vsyscall_tz().

Locking is not only unnecessary because the vdso code copies the data
unprotected in __kernel_gettimeofday() but also erroneous because updating
the tb_update_count is not atomic and introduces a hard to reproduce race
condition between update_vsyscall() and update_vsyscall_tz(), which further
causes user space process to loop forever in vdso code.

The below scenario describes the race condition,
x==0	Boot CPU			other CPU
	proc_P: x==0
	    timer interrupt
		update_vsyscall
x==1		    x++;sync		settimeofday
					    update_vsyscall_tz
x==2						x++;sync
x==3		    sync;x++
						sync;x++
	proc_P: x==3 (loops until x becomes even)

Because the ++ operator would be implemented as three instructions and not
atomic on powerpc.

A similar change was made for x86 in commit 6c260d58634
("x86: vdso: Remove bogus locking in update_vsyscall_tz")

Signed-off-by: Shan Hai 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc: Fix CONFIG_RELOCATABLE=y CONFIG_CRASH_DUMP=n build

2013-01-17T16:45:45+00:00

commit 11ee7e99f35ecb15f59b21da6a82d96d2cd3fcc8 upstream.

If we build a kernel with CONFIG_RELOCATABLE=y CONFIG_CRASH_DUMP=n,
the kernel fails when we run at a non zero offset. It turns out
we were incorrectly wrapping some of the relocatable kernel code
with CONFIG_CRASH_DUMP.

Signed-off-by: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

s390/kvm: Fix address space mixup

2013-01-17T16:45:44+00:00

commit ce6a04ac1b759beafc88dbc443ae5da867579eeb upstream.

I was chasing down a bug of random validity intercepts on s390.
(guest prefix page not mapped in the host virtual aspace). Turns out
that the problem was a wrong address space control element. The
cause was quite complex:

During paging activity a DAT protection during SIE caused a program
interrupt. Normally, the sie retry loop tries to catch all
interrupts during and shortly before sie to rerun the setup. The
problem is now that protection causes a suppressing program interrupt,
causing the PSW to point to the instruction AFTER SIE in case of DAT
protection. This confused the logic of the retry loop to not trigger,
instead we jumped directly back to SIE after return from
the program  interrupt. (the protection fault handler itself did
a rewind of the psw). This usually works quite well, but:

If now the protection fault handler has to wait, another program
might be scheduled in. Later on the sie process will be schedules
in again. In that case the content of CR1 (primary address space)
will be wrong because switch_to will put the user space ASCE into CR1
and not the guest ASCE.

In addition the program parameter is also wrong for every protection
fault of a guest, since we dont issue the SPP instruction.

So lets also check for PSW == instruction after SIE in the program
check handler. Instead of expensively checking all program
interruption codes that might be suppressing we assume that a program
interrupt pointing after SIE was always a program interrupt in SIE.
(Otherwise we have a kernel bug anyway).

We also have to compensate the rewinding, since the C-level handlers
will do that. Therefore we need to add a nop with the same length
as SIE before the sie_loop.

Signed-off-by: Christian Borntraeger 
Signed-off-by: Martin Schwidefsky 
CC: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman