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

ARM: Kirkwood: Update PCI-E fixup

2012-12-06T11:20:34+00:00

commit 1dc831bf53fddcc6443f74a39e72db5bcea4f15d upstream.

- The code relies on rc_pci_fixup being called, which only happens
  when CONFIG_PCI_QUIRKS is enabled, so add that to Kconfig. Omitting
  this causes a booting failure with a non-obvious cause.
- Update rc_pci_fixup to set the class properly, copying the
  more modern style from other places
- Correct the rc_pci_fixup comment

Signed-off-by: Jason Gunthorpe 
Signed-off-by: Jason Cooper 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

Dove: Fix irq_to_pmu()

2012-12-06T11:20:33+00:00

commit d356cf5a74afa32b40decca3c9dd88bc3cd63eb5 upstream.

PMU interrupts start at IRQ_DOVE_PMU_START, not IRQ_DOVE_PMU_START + 1.
Fix the condition.  (It may have been less likely to occur had the code
been written "if (irq >= IRQ_DOVE_PMU_START" which imho is the easier
to understand notation, and matches the normal way of thinking about
these things.)

Signed-off-by: Russell King 
Signed-off-by: Jason Cooper 
Signed-off-by: Ben Hutchings

Dove: Attempt to fix PMU/RTC interrupts

2012-12-06T11:20:33+00:00

commit 5d3df935426271016b895aecaa247101b4bfa35e upstream.

Fix the acknowledgement of PMU interrupts on Dove: some Dove hardware
has not been sensibly designed so that interrupts can be handled in a
race free manner.  The PMU is one such instance.

The pending (aka 'cause') register is a bunch of RW bits, meaning that
these bits can be both cleared and set by software (confirmed on the
Armada-510 on the cubox.)

Hardware sets the appropriate bit when an interrupt is asserted, and
software is required to clear the bits which are to be processed.  If
we write ~(1 << bit), then we end up asserting every other interrupt
except the one we're processing.  So, we need to do a read-modify-write
cycle to clear the asserted bit.

However, any interrupts which occur in the middle of this cycle will
also be written back as zero, which will also clear the new interrupts.

The upshot of this is: there is _no_ way to safely clear down interrupts
in this register (and other similarly behaving interrupt pending
registers on this device.)  The patch below at least stops us creating
new interrupts.

Signed-off-by: Russell King 
Signed-off-by: Jason Cooper 
Signed-off-by: Ben Hutchings

ARM: at91/i2c: change id to let i2c-gpio work

2012-11-16T16:46:55+00:00

commit 7840487cd6298f9f931103b558290d8d98d41c49 upstream.

The i2c core driver will turn the platform device ID to busnum
When using platfrom device ID as -1, it means dynamically assigned
the busnum. When writing code, we need to make sure the busnum,
and call i2c_register_board_info(int busnum, ...) to register device
if using -1, we do not know the value of busnum

In order to solve this issue, set the platform device ID as a fix number
Here using 0 to match the busnum used in i2c_regsiter_board_info()

Signed-off-by: Bo Shen 
Acked-by: Jean Delvare 
Signed-off-by: Nicolas Ferre 
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 
Acked-by: Ludovic Desroches 
Signed-off-by: Ben Hutchings

ARM: at91: at91sam9g10: fix SOC type detection

2012-11-16T16:46:55+00:00

commit 3d9a0183dd3423353e9e363bcc261c1220d05f9f upstream.

Newer at91sam9g10 SoC revision can't be detected, so the kernel can't boot with
this kind of kernel panic:
"AT91: Impossible to detect the SOC type"

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Atmel AT91SAM9G10-EK
Ignoring tag cmdline (using the default kernel command line)
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writeback
Kernel panic - not syncing: AT91: Impossible to detect the SOC type
[] (unwind_backtrace+0x0/0xe0) from [] (panic+0x78/0x1cc)
[] (panic+0x78/0x1cc) from [] (at91_map_io+0x90/0xc8)
[] (at91_map_io+0x90/0xc8) from [] (paging_init+0x564/0x6d0)
[] (paging_init+0x564/0x6d0) from [] (setup_arch+0x464/0x704)
[] (setup_arch+0x464/0x704) from [] (start_kernel+0x6c/0x2d4)
[] (start_kernel+0x6c/0x2d4) from [<20008040>] (0x20008040)

The reason for this is that the Debug Unit Chip ID Register has changed between
Engineering Sample and definitive revision of the SoC. Changing the check of
cidr to socid will address the problem. We do not integrate this check to the
list just above because we also have to make sure that the extended id is
disregarded.

Signed-off-by: Ivan Shugov 
[nicolas.ferre@atmel.com: change commit message]
Signed-off-by: Nicolas Ferre 
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 
Signed-off-by: Ben Hutchings

ARM: 7559/1: smp: switch away from the idmap before updating init_mm.mm_count

2012-10-30T23:26:54+00:00

commit 5f40b909728ad784eb43aa309d3c4e9bdf050781 upstream.

When booting a secondary CPU, the primary CPU hands two sets of page
tables via the secondary_data struct:

	(1) swapper_pg_dir: a normal, cacheable, shared (if SMP) mapping
	    of the kernel image (i.e. the tables used by init_mm).

	(2) idmap_pgd: an uncached mapping of the .idmap.text ELF
	    section.

The idmap is generally used when enabling and disabling the MMU, which
includes early CPU boot. In this case, the secondary CPU switches to
swapper as soon as it enters C code:

	struct mm_struct *mm = &init_mm;
	unsigned int cpu = smp_processor_id();

	/*
	 * All kernel threads share the same mm context; grab a
	 * reference and switch to it.
	 */
	atomic_inc(&mm->mm_count);
	current->active_mm = mm;
	cpumask_set_cpu(cpu, mm_cpumask(mm));
	cpu_switch_mm(mm->pgd, mm);

This causes a problem on ARMv7, where the identity mapping is treated as
strongly-ordered leading to architecturally UNPREDICTABLE behaviour of
exclusive accesses, such as those used by atomic_inc.

This patch re-orders the secondary_start_kernel function so that we
switch to swapper before performing any exclusive accesses.

Cc: David McKay 
Reported-by: Gilles Chanteperdrix 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels

2012-10-30T23:26:38+00:00

commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 upstream.

Michael Olbrich reported that his test program fails when built with
-O2 -mcpu=cortex-a8 -mfpu=neon, and a kernel which supports v6 and v7
CPUs:

volatile int x = 2;
volatile int64_t y = 2;

int main() {
	volatile int a = 0;
	volatile int64_t b = 0;
	while (1) {
		a = (a + x) % (1 << 30);
		b = (b + y) % (1 << 30);
		assert(a == b);
	}
}

and two instances are run.  When built for just v7 CPUs, this program
works fine.  It uses the "vadd.i64 d19, d18, d16" VFP instruction.

It appears that we do not save the high-16 double VFP registers across
context switches when the kernel is built for v6 CPUs.  Fix that.

Tested-By: Michael Olbrich 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: OMAP: counter: add locking to read_persistent_clock

2012-10-17T02:49:44+00:00

commit 9d7d6e363b06934221b81a859d509844c97380df upstream.

read_persistent_clock uses a global variable, use a spinlock to
ensure non-atomic updates to the variable don't overlap and cause
time to move backwards.

Signed-off-by: Colin Cross 
Signed-off-by: R Sricharan 
Signed-off-by: Tony Lindgren 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

ARM: 7532/1: decompressor: reset SCTLR.TRE for VMSA ARMv7 cores

2012-10-10T02:30:53+00:00

commit e1e5b7e4251c7538ca08c2c5545b0c2fbd8a6635 upstream.

This patch zeroes the SCTLR.TRE bit prior to setting the mapping as
cacheable for ARMv7 cores in the decompressor, ensuring that the
memory region attributes are obtained from the C and B bits, not from
the page tables.

Cc: Nicolas Pitre 
Reviewed-by: Will Deacon 
Signed-off-by: Matthew Leach 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: 7526/1: traps: send SIGILL if get_user fails on undef handling path

2012-09-19T14:05:18+00:00

commit 2b2040af0b64cd93e5d4df2494c4486cf604090d upstream.

get_user may fail to load from the provided __user address due to an
unhandled fault generated by the access.

In the case of the undefined instruction trap, this results in failure
to load the faulting instruction, in which case we should send SIGILL to
the task rather than continue with potentially uninitialised data.

Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings