kernel.git/arch/arm/Kconfig, branch linux-3.2.y

locking/mutex: Disable optimistic spinning on some architectures

2014-08-06T17:07:38Z

commit 4badad352a6bb202ec68afa7a574c0bb961e5ebc upstream. The optimistic spin code assumes regular stores and cmpxchg() play nice; this is found to not be true for at least: parisc, sparc32, tile32, metag-lock1, arc-!llsc and hexagon. There is further wreckage, but this in particular seemed easy to trigger, so blacklist this. Opt in for known good archs. Signed-off-by: Peter Zijlstra Reported-by: Mikulas Patocka Cc: David Miller Cc: Chris Metcalf Cc: James Bottomley Cc: Vineet Gupta Cc: Jason Low Cc: Waiman Long Cc: "James E.J. Bottomley" Cc: Paul McKenney Cc: John David Anglin Cc: James Hogan Cc: Linus Torvalds Cc: Davidlohr Bueso Cc: Benjamin Herrenschmidt Cc: Catalin Marinas Cc: Russell King Cc: Will Deacon Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: sparclinux@vger.kernel.org Link: http://lkml.kernel.org/r/20140606175316.GV13930@laptop.programming.kicks-ass.net Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: - Adjust context - Drop arm64 change] Signed-off-by: Ben Hutchings

ARM: 7791/1: a.out: remove partial a.out support

2013-09-10T00:57:14Z

commit acfdd4b1f7590d02e9bae3b73bdbbc4a31b05d38 upstream. a.out support on ARM requires that argc, argv and envp are passed in r0-r2 respectively, which requires hacking load_aout_binary to prevent argc being clobbered by the return code. Whilst mainline kernels do set the registers up in start_thread, the aout loader has never carried the hack in mainline. Initialising the registers in this way actually goes against the libc expectations for ELF binaries, where argc, argv and envp are passed on the stack, with r0 being used to hold a pointer to an exit function for cleaning up after the dynamic linker if required. If the pointer is NULL, then it is ignored. When execing an ELF binary, Linux currently zeroes r0, then sets it to argc and then finally clobbers it with the return value of the execve syscall, so we actually end up with: r0 = 0 stack[0] = argc r1 = stack[1] = argv r2 = stack[2] = envp libc treats r1 and r2 as undefined. The clobbering of r0 by sys_execve works for user-spawned threads, but when executing an ELF binary from a kernel thread (via call_usermodehelper), the execve is performed on the ret_from_fork path, which restores r0 from the saved pt_regs, resulting in argc being presented to the C library. This has horrible consequences when the application exits, since we have an exit function registered using argc, resulting in a jump to hyperspace. This patch solves the problem by removing the partial a.out support from arch/arm/ altogether. Cc: Ashish Sangwan Signed-off-by: Will Deacon Signed-off-by: Russell King [bwh: Backported to 3.2: - Adjust context - Adjust uapi filename] Signed-off-by: Ben Hutchings

ARM: Kirkwood: Update PCI-E fixup

2012-12-06T11:20:34Z

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

ARM: imx: select CPU_FREQ_TABLE when needed

2012-09-19T14:04:32Z

commit f637c4c9405e21f44cf0045eaf77eddd3a79ca5a upstream. The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers, so it needs to select that code to be built. This problem has apparently existed since the i.MX cpufreq code was first merged in v2.6.37. Building IMX without CPU_FREQ_TABLE results in: arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit': arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr' arch/arm/plat-mxc/built-in.o: In function `mxc_set_target': arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target' arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed': arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify' arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init': arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo' arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr' Signed-off-by: Arnd Bergmann Acked-by: Shawn Guo Cc: Sascha Hauer Cc: Yong Shen Signed-off-by: Ben Hutchings

ixp4xx: fix compilation by adding gpiolib support

2012-06-10T13:41:34Z

commit 9dde0ae3769875ec1370cb316e50c54b57d52c1a upstream. Once again, ixp4xx no longer even compiles. This patch fixes the issue by converting over to gpiolib. This patch was first made by Imre and posted by Marc, and I added in Russell's suggestion to empty the gpio header file. This fix should also go for 3.1, 3.2, 3.3, and 3.4. Signed-off-by: Richard Cochran Signed-off-by: Arnd Bergmann Signed-off-by: Ben Hutchings

ARM: 7396/1: errata: only handle ARM erratum #326103 on affected cores

2012-05-11T12:14:44Z

commit f0c4b8d653f5ee091fb8d4d02ed7eaad397491bb upstream. Erratum #326103 ("FSR write bit incorrect on a SWP to read-only memory") only affects the ARM 1136 core prior to r1p0. The workaround disassembles the faulting instruction to determine whether it was a read or write access on all v6 cores. An issue has been reported on the ARM 11MPCore whereby loading the faulting instruction may happen in parallel with that page being unmapped, resulting in a deadlock due to the lack of TLB broadcasting in hardware: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/091561.html This patch limits the workaround so that it is only used on affected cores, which are known to be UP only. Other v6 cores can rely on the FSR to indicate the access type correctly. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Ben Hutchings

ARM: 7345/1: errata: update workaround for A9 erratum #743622

2012-03-12T19:31:38Z

commit efbc74ace95338484f8d732037b99c7c77098fce upstream. Erratum #743622 affects all r2 variants of the Cortex-A9 processor, so ensure that the workaround is applied regardless of the revision. Reported-by: Russell King Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 7197/1: errata: Remove SMP dependency for erratum 751472

2011-12-23T22:34:48Z

Activation conditions for a workaround should not be encoded in the workaround's direct dependencies if this makes otherwise reasonable configuration choices impossible. This patches uses the SMP/UP patching facilities instead to compile out the workaround if the configuration means that it is definitely not needed. This means that configs for buggy silicon can simply select ARM_ERRATA_751472, without preventing a UP kernel from being built or duplicatiing knowledge about when to activate the workaround. This seems the correct way to do things, because the erratum is a property of the silicon, irrespective of what the kernel config happens to be. Signed-off-by: Dave Martin Signed-off-by: Russell King

ARM: 7196/1: errata: Remove SMP dependency for erratum 720789

2011-12-23T22:34:47Z

Activation conditions for a workaround should not be encoded in the workaround's direct dependencies if this makes otherwise reasonable configuration choices impossible. The workaround for erratum 720789 only affects a code path which is not active in UP kernels; hence it should be safe to turn on in UP kernels, without penalty. This patch simply removes the extra dependency on SMP from Kconfig. This means that configs for buggy silicon can simply select ARM_ERRATA_720789, without preventing a UP kernel from being built or duplicatiing knowledge about when to activate the workaround. Signed-off-by: Dave Martin Acked-by: Will Deacon Signed-off-by: Russell King

ARM: 7186/1: fix Kconfig issue with PHYS_OFFSET and !MMU

2011-12-06T11:16:13Z

Commit 1b9f95f8ade9 (ARM: prepare for removal of a bunch of files) introduced CONFIG_PHYS_OFFSET but the Kconfig hex prompt did not provide a default value. This has the undesired side effect of breaking a reportedly used trick for updating defconfigs on the fly for routine buildtesting across all arch and all platforms, i.e. cp /path/to/somedefconfig .config ; yes "" | make oldconfig because the config system will endlessly loop until a valid address is provided. However we can't just pick a random default value since it is likely to be wrong for the majority of the boards as the right answer for this option is quite varied. So the fact that the config system insists on having a proper value be entered is actually a good thing. It turns out that only at91x40_defconfig has this problem because it has CONFIG_MMU=n. However, in the !MMU case, there is already a CONFIG_DRAM_BASE value that can be used here. So let's use that as a default in that case and suppress the redundant CONFIG_PHYS_OFFSET prompt. Eventually the DRAM_BASE config option could simply be replaced by PHYS_OFFSET directly, but that's a larger change better suited for later. Reported-by: Paul Gortmaker Signed-off-by: Nicolas Pitre Acked-by: Uwe Kleine-König Signed-off-by: Russell King