user/sven/linux.git/arch, branch v3.4.48

x86, um: Correct syscall table type attributes breaking gcc 4.8

2013-06-07T19:49:48Z

commit 9271b0b4b2044c6db06051fe60bc58cdd4f17c7c upstream. The latest GCC 4.8 does some more checking on type attributes that break the build for ARCH=um -> fill them in. Specifically, the "asmlinkage" attributes is now tested for consistency. Signed-off-by: Martin Pelikan Link: http://lkml.kernel.org/r/1339269731-10772-1-git-send-email-pelikan@storkhole.cz Acked-by: Richard Weinberger Signed-off-by: H. Peter Anvin Cc: Bernhard M. Wiedemann Signed-off-by: Greg Kroah-Hartman

m68k/mac: Fix unexpected interrupt with CONFIG_EARLY_PRINTK

2013-06-07T19:49:34Z

commit df66834a43c461de2565c45d815288ba1c0def37 upstream. The present code does not wait for the SCC to finish resetting itself before trying to initialise the device. The result is that the SCC interrupt sources become enabled (if they weren't already). This leads to an early boot crash (unexpected interrupt) given CONFIG_EARLY_PRINTK. Fix this by adding a delay. A successful reset disables the interrupt sources. Also, after the reset for channel A setup, the SCC then gets a second reset for channel B setup which leaves channel A uninitialised again. Fix this by performing the reset only once. Signed-off-by: Finn Thain Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman

Kirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x

2013-06-07T19:49:13Z

commit 99e11334dcb846f9b76fb808196c7f47aa83abb3 upstream. Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions (rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1. Thanks to Marek Vasut for identifying this issue! Signed-off-by: Martin Michlmayr Tested-by: Marek Vasut Acked-by: Andrew Lunn Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman

ARM: plat-orion: Fix num_resources and id for ge10 and ge11

2013-06-07T19:49:10Z

commit 2b8b2797142c7951e635c6eec5d1705ee9bc45c5 upstream. When platform data were moved from arch/arm/mach-mv78xx0/common.c to arch/arm/plat-orion/common.c with the commit "7e3819d ARM: orion: Consolidate ethernet platform data", there were few typo made on gigabit Ethernet interface ge10 and ge11. This commit writes back their initial value, which allows to use this interfaces again. Signed-off-by: Gregory CLEMENT Acked-by: Andrew Lunn Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman

avr32: fix relocation check for signed 18-bit offset

2013-06-07T19:49:10Z

commit e68c636d88db3fda74e664ecb1a213ae0d50a7d8 upstream. Caught by static code analysis by David. Reported-by: David Binderman Signed-off-by: Hans-Christian Egtvedt Signed-off-by: Greg Kroah-Hartman

powerpc: Bring all threads online prior to migration/hibernation

2013-05-19T17:54:40Z

commit 120496ac2d2d60aee68d3123a68169502a85f4b5 upstream. This patch brings online all threads which are present but not online prior to migration/hibernation. After migration/hibernation those threads are taken back offline. During migration/hibernation all online CPUs must call H_JOIN, this is required by the hypervisor. Without this patch, threads that are offline (H_CEDE'd) will not be woken to make the H_JOIN call and the OS will be deadlocked (all threads either JOIN'd or CEDE'd). Signed-off-by: Robert Jennings Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

xen/vcpu/pvhvm: Fix vcpu hotplugging hanging.

2013-05-19T17:54:38Z

commit 7f1fc268c47491fd5e63548f6415fc8604e13003 upstream. If a user did: echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online we would (this a build with DEBUG enabled) get to: smpboot: ++++++++++++++++++++=_---CPU UP 1 .. snip.. smpboot: Stack at about ffff880074c0ff44 smpboot: CPU1: has booted. and hang. The RCU mechanism would kick in an try to IPI the CPU1 but the IPIs (and all other interrupts) would never arrive at the CPU1. At first glance at least. A bit digging in the hypervisor trace shows that (using xenanalyze): [vla] d4v1 vec 243 injecting 0.043163027 --|x d4v1 intr_window vec 243 src 5(vector) intr f3 ] 0.043163639 --|x d4v1 vmentry cycles 1468 ] 0.043164913 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254 0.043164913 --|x d4v1 inj_virq vec 243 real [vla] d4v1 vec 243 injecting 0.043164913 --|x d4v1 intr_window vec 243 src 5(vector) intr f3 ] 0.043165526 --|x d4v1 vmentry cycles 1472 ] 0.043166800 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254 0.043166800 --|x d4v1 inj_virq vec 243 real [vla] d4v1 vec 243 injecting there is a pending event (subsequent debugging shows it is the IPI from the VCPU0 when smpboot.c on VCPU1 has done "set_cpu_online(smp_processor_id(), true)") and the guest VCPU1 is interrupted with the callback IPI (0xf3 aka 243) which ends up calling __xen_evtchn_do_upcall. The __xen_evtchn_do_upcall seems to do *something* but not acknowledge the pending events. And the moment the guest does a 'cli' (that is the ffffffff81673254 in the log above) the hypervisor is invoked again to inject the IPI (0xf3) to tell the guest it has pending interrupts. This repeats itself forever. The culprit was the per_cpu(xen_vcpu, cpu) pointer. At the bootup we set each per_cpu(xen_vcpu, cpu) to point to the shared_info->vcpu_info[vcpu] but later on use the VCPUOP_register_vcpu_info to register per-CPU structures (xen_vcpu_setup). This is used to allow events for more than 32 VCPUs and for performance optimizations reasons. When the user performs the VCPU hotplug we end up calling the the xen_vcpu_setup once more. We make the hypercall which returns -EINVAL as it does not allow multiple registration calls (and already has re-assigned where the events are being set). We pick the fallback case and set per_cpu(xen_vcpu, cpu) to point to the shared_info->vcpu_info[vcpu] (which is a good fallback during bootup). However the hypervisor is still setting events in the register per-cpu structure (per_cpu(xen_vcpu_info, cpu)). As such when the events are set by the hypervisor (such as timer one), and when we iterate in __xen_evtchn_do_upcall we end up reading stale events from the shared_info->vcpu_info[vcpu] instead of the per_cpu(xen_vcpu_info, cpu) structures. Hence we never acknowledge the events that the hypervisor has set and the hypervisor keeps on reminding us to ack the events which we never do. The fix is simple. Don't on the second time when xen_vcpu_setup is called over-write the per_cpu(xen_vcpu, cpu) if it points to per_cpu(xen_vcpu_info). Acked-by: Stefano Stabellini Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

ARM: OMAP: RX-51: change probe order of touchscreen and panel SPI devices

2013-05-19T17:54:34Z

commit e65f131a14726e5f1b880a528271a52428e5b3a5 upstream. Commit 9fdca9df (spi: omap2-mcspi: convert to module_platform_driver) broke the SPI display/panel driver probe on RX-51/N900. The exact cause is not fully understood, but it seems to be related to the probe order. SPI communication to the panel driver (spi1.2) fails unless the touchscreen (spi1.0) has been probed/initialized before. When the omap2-mcspi driver was converted to a platform driver, it resulted in that the devices are probed immediately after the board registers them in the order they are listed in the board file. Fix the issue by moving the touchscreen before the panel in the SPI device list. The patch fixes the following failure: [ 1.260955] acx565akm spi1.2: invalid display ID [ 1.265899] panel-acx565akm display0: acx_panel_probe panel detect error [ 1.273071] omapdss CORE error: driver probe failed: -19 Tested-by: Sebastian Reichel Signed-off-by: Aaro Koskinen Cc: Pali Rohár Cc: Joni Lapilainen Cc: Tomi Valkeinen Cc: Felipe Balbi Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman

KVM: VMX: fix halt emulation while emulating invalid guest sate

2013-05-19T17:54:34Z

commit 8d76c49e9ffeee839bc0b7a3278a23f99101263e upstream. The invalid guest state emulation loop does not check halt_request which causes 100% cpu loop while guest is in halt and in invalid state, but more serious issue is that this leaves halt_request set, so random instruction emulated by vm86 #GP exit can be interpreted as halt which causes guest hang. Fix both problems by handling halt_request in emulation loop. Reported-by: Tomas Papan Tested-by: Tomas Papan Reviewed-by: Paolo Bonzini Signed-off-by: Gleb Natapov Signed-off-by: Greg Kroah-Hartman

x86/mm: account for PGDIR_SIZE alignment

2013-05-11T20:48:15Z

Patch for -stable. Function find_early_table_space removed upstream. Fixes panic in alloc_low_page due to pgt_buf overflow during init_memory_mapping. find_early_table_space sizes pgt_buf based upon the size of the memory being mapped, but it does not take into account the alignment of the memory. When the region being mapped spans a 512GB (PGDIR_SIZE) alignment, a panic from alloc_low_pages occurs. kernel_physical_mapping_init takes into account PGDIR_SIZE alignment. This causes an extra call to alloc_low_page to be made. This extra call isn't accounted for by find_early_table_space and causes a kernel panic. Change is to take into account PGDIR_SIZE alignment in find_early_table_space. Signed-off-by: Jerry Hoemann Signed-off-by: Greg Kroah-Hartman