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

arch/tile: apply commit 74fca9da0 to the compat signal handling as well

2012-05-20T21:56:50+00:00

commit a134d228298c6aa9007205c6b81cae0cac0acb5d upstream.

This passes siginfo and mcontext to tilegx32 signal handlers that
don't have SA_SIGINFO set just as we have been doing for tilegx64.

Signed-off-by: Chris Metcalf 
Signed-off-by: Ben Hutchings

ARM: prevent VM_GROWSDOWN mmaps extending below FIRST_USER_ADDRESS

2012-05-20T21:56:49+00:00

commit 9b61a4d1b2064dbd0c9e61754305ac852170509f upstream.

Reported-by: Al Viro 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: 7417/1: vfp: ensure preemption is disabled when enabling VFP access

2012-05-20T21:56:46+00:00

commit 998de4acb2ba188d20768d1065658377a2e7d29b upstream.

The vfp_enable function enables access to the VFP co-processor register
space (cp10 and cp11) on the current CPU and must be called with
preemption disabled. Unfortunately, the vfp_init late initcall does not
disable preemption and can lead to an oops during boot if thread
migration occurs at the wrong time and we end up attempting to access
the FPSID on a CPU with VFP access disabled.

This patch fixes the initcall to call vfp_enable from a non-preemptible
context on each CPU and adds a BUG_ON(preemptible) to ensure that any
similar problems are easily spotted in the future.

Reported-by: Hyungwoo Yang 
Signed-off-by: Hyungwoo Yang 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ia64: Add accept4() syscall

2012-05-20T21:56:46+00:00

commit 65cc21b4523e94d5640542a818748cd3be8cd6b4 upstream.

While debugging udev > 170 failure on Debian Wheezy
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648325), it appears
that the issue was in fact due to missing accept4() in ia64.

This patch simply adds accept4() to ia64.

Signed-off-by: Émeric Maschino 
Signed-off-by: Tony Luck 
Signed-off-by: Ben Hutchings

sparc64: Do not clobber %g2 in xcall_fetch_glob_regs().

2012-05-20T21:56:42+00:00

[ Upstream commit a5a737e090e25981e99d69f01400e3a80356581c ]

%g2 is meant to hold the CPUID number throughout this routine, since
at the very beginning, and at the very end, we use %g2 to calculate
indexes into per-cpu arrays.

However we erroneously clobber it in order to hold the %cwp register
value mid-stream.

Fix this code to use %g3 for the %cwp read and related calulcations
instead.

Reported-by: Meelis Roos 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

ARM: orion5x: Fix GPIO enable bits for MPP9

2012-05-20T21:56:31+00:00

commit 48d99f47a81a66bdd61a348c7fe8df5a7afdf5f3 upstream.

Commit 554cdaefd1cf7bb54b209c4e68c7cec87ce442a9 ('ARM: orion5x: Refactor
mpp code to use common orion platform mpp.') seems to have accidentally
inverted the GPIO valid bits for MPP9 (only).  For the mv2120 platform
which uses MPP9 as a GPIO LED device, this results in the error:

[   12.711476] leds-gpio: probe of leds-gpio failed with error -22

Reported-by: Henry von Tresckow 
References: http://bugs.debian.org/667446
Signed-off-by: Ben Hutchings 
Tested-by: Hans Henry von Tresckow 
Signed-off-by: Jason Cooper

ARM: OMAP: Revert "ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields"

2012-05-20T21:56:29+00:00

commit 08ca7444f589bedf9ad5d82883e5d0754852d73b upstream.

This reverts commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237.

The commit above swapped the DSI1_PPID and DSI2_PPID register fields in
CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V).

With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs.
After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the
DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was
pulling up voltage on DSI2 lanes.

This proves that the current version of OMAP4 TRM is incorrect, swap the
position of register fields according to the older TRM versions as they were
correct.

Acked-by: Tomi Valkeinen 
Signed-off-by: Archit Taneja 
Signed-off-by: Tony Lindgren 
Signed-off-by: Ben Hutchings

percpu, x86: don't use PMD_SIZE as embedded atom_size on 32bit

2012-05-11T12:15:01+00:00

commit d5e28005a1d2e67833852f4c9ea8ec206ea3ff85 upstream.

With the embed percpu first chunk allocator, x86 uses either PAGE_SIZE
or PMD_SIZE for atom_size.  PMD_SIZE is used when CPU supports PSE so
that percpu areas are aligned to PMD mappings and possibly allow using
PMD mappings in vmalloc areas in the future.  Using larger atom_size
doesn't waste actual memory; however, it does require larger vmalloc
space allocation later on for !first chunks.

With reasonably sized vmalloc area, PMD_SIZE shouldn't be a problem
but x86_32 at this point is anything but reasonable in terms of
address space and using larger atom_size reportedly leads to frequent
percpu allocation failures on certain setups.

As there is no reason to not use PMD_SIZE on x86_64 as vmalloc space
is aplenty and most x86_64 configurations support PSE, fix the issue
by always using PMD_SIZE on x86_64 and PAGE_SIZE on x86_32.

v2: drop cpu_has_pse test and make x86_64 always use PMD_SIZE and
    x86_32 PAGE_SIZE as suggested by hpa.

Signed-off-by: Tejun Heo 
Reported-by: Yanmin Zhang 
Reported-by: ShuoX Liu 
Acked-by: H. Peter Anvin 
LKML-Reference: <4F97BA98.6010001@intel.com>
Signed-off-by: Ben Hutchings

xen/pci: don't use PCI BIOS service for configuration space accesses

2012-05-11T12:15:00+00:00

commit 76a8df7b49168509df02461f83fab117a4a86e08 upstream.

The accessing PCI configuration space with the PCI BIOS32 service does
not work in PV guests.

On systems without MMCONFIG or where the BIOS hasn't marked the
MMCONFIG region as reserved in the e820 map, the BIOS service is
probed (even though direct access is preferred) and this hangs.

Acked-by: Jan Beulich 
Signed-off-by: David Vrabel 
[v1: Fixed compile error when CONFIG_PCI is not set]
Signed-off-by: Konrad Rzeszutek Wilk 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs

2012-05-11T12:15:00+00:00

commit b7e5ffe5d83fa40d702976d77452004abbe35791 upstream.

If I try to do "cat /sys/kernel/debug/kernel_page_tables"
I end up with:

BUG: unable to handle kernel paging request at ffffc7fffffff000
IP: [] ptdump_show+0x221/0x480
PGD 0
Oops: 0000 [#1] SMP
CPU 0
.. snip..
RAX: 0000000000000000 RBX: ffffc00000000fff RCX: 0000000000000000
RDX: 0000800000000000 RSI: 0000000000000000 RDI: ffffc7fffffff000

which is due to the fact we are trying to access a PFN that is not
accessible to us. The reason (at least in this case) was that
PGD[256] is set to __HYPERVISOR_VIRT_START which was setup (by the
hypervisor) to point to a read-only linear map of the MFN->PFN array.
During our parsing we would get the MFN (a valid one), try to look
it up in the MFN->PFN tree and find it invalid and return ~0 as PFN.
Then pte_mfn_to_pfn would happilly feed that in, attach the flags
and return it back to the caller. 'ptdump_show' bitshifts it and
gets and invalid value that it tries to dereference.

Instead of doing all of that, we detect the ~0 case and just
return !_PAGE_PRESENT.

This bug has been in existence .. at least until 2.6.37 (yikes!)

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings