linux/arch/mips, branch v3.8.6

MIPS: Function tracer: Fix broken function tracing

2013-01-31T14:28:48Z

Function tracing is currently broken for all 32 bit MIPS platforms. When tracing is enabled, the kernel immediately hangs on boot. This is a result of commit b732d439cb43336cd6d7e804ecb2c81193ef63b0 that changes the kernel/trace/Kconfig file so that is no longer forces FRAME_POINTER when FUNCTION_TRACING is enabled. MIPS frame pointers are generally considered to be useless because they cannot be used to unwind the stack. Unfortunately the MIPS function tracing code has bugs that are masked by the use of frame pointers. This commit fixes the bugs so that MIPS frame pointers don't need to be enabled. The bugs are a result of the odd calling sequence used to call the trace routine. This calling sequence is inserted into every traceable function when the tracing CONFIG option is enabled. This sequence is generated for 32bit MIPS platforms by the compiler via the "-pg" flag. Part of the sequence is "addiu sp,sp,-8" in the delay slot after every call to the trace routine "_mcount" (some legacy thing where 2 arguments used to be pushed on the stack). The _mcount routine is expected to adjust the sp by +8 before returning. So when not disabled, the original jalr and addiu will be there, so _mcount has to adjust sp. The problem is that when tracing is disabled for a function, the "jalr _mcount" instruction is replaced with a nop, but the "addiu sp,sp,-8" is still executed and the stack pointer is left trashed. When frame pointers are enabled the problem is masked because any access to the stack is done through the frame pointer and the stack pointer is restored from the frame pointer when the function returns. This patch writes two nops starting at the address of the "jalr _mcount" instruction whenever tracing is disabled. This means that the "addiu sp,sp.-8" will be converted to a nop along with the "jalr". When disabled, there will be two nops. This is SMP safe because the first time this happens is during ftrace_init() which is before any other processor has been started. Subsequent calls to enable/disable tracing when other CPUs ARE running will still be safe because the enable will only change the first nop to a "jalr" and the disable, while writing 2 nops, will only be changing the "jalr". This patch also stops using stop_machine() to call the tracer enable/disable routines and calls them directly because the routines are SMP safe. When the kernel first boots we have to be able to handle the gcc generated jalr, addui sequence until ftrace_init gets a chance to run and change the sequence. At this point mcount just adjusts the stack and returns. When ftrace_init runs, we convert the jalr/addui to nops. Then whenever tracing is enabled we convert the first nop to a "jalr mcount+8". The mcount+8 entry point skips the stack adjust. [ralf@linux-mips.org: Folded in Steven Rostedt's build fix.] Signed-off-by: Al Cooper Cc: rostedt@goodmis.org Cc: ddaney.cavm@gmail.com Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/4806/ Patchwork: https://patchwork.linux-mips.org/patch/4841/ Signed-off-by: Ralf Baechle

mips: Move __virt_addr_valid() to a place for MIPS 64

2013-01-31T14:14:59Z

Commit d3ce88431892 "MIPS: Fix modpost error in modules attepting to use virt_addr_valid()" moved __virt_addr_valid() from a macro in a header file to a function in ioremap.c. But ioremap.c is only compiled for MIPS 32, and not for MIPS 64. When compiling for my yeeloong2, which supposedly supports hibernation, which compiles kernel/power/snapshot.c which calls virt_addr_valid(), I got this error: LD init/built-in.o kernel/built-in.o: In function `memory_bm_free': snapshot.c:(.text+0x4c9c4): undefined reference to `__virt_addr_valid' snapshot.c:(.text+0x4ca58): undefined reference to `__virt_addr_valid' kernel/built-in.o: In function `snapshot_write_next': (.text+0x4e44c): undefined reference to `__virt_addr_valid' kernel/built-in.o: In function `snapshot_write_next': (.text+0x4e890): undefined reference to `__virt_addr_valid' make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2 I suspect that __virt_addr_valid() is fine for mips 64. I moved it to mmap.c such that it gets compiled for mips 64 and 32. Signed-off-by: Steven Rostedt Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/4842/ Signed-off-by: Ralf Baechle

MIPS: Netlogic: Fix UP compilation on XLR

2013-01-30T20:44:18Z

The commit 2a37b1a "MIPS: Netlogic: Move from u32 cpumask to cpumask_t" breaks uniprocessor compilation on XLR with: arch/mips/netlogic/xlr/setup.c: In function 'prom_init': arch/mips/netlogic/xlr/setup.c:196:6: error: unused variable 'i' Fix by defining 'i' only when CONFIG_SMP is defined. Signed-off-by: Jayachandran C Patchwork: http://patchwork.linux-mips.org/patch/4760/ Signed-off-by: John Crispin Signed-off-by: Ralf Baechle

MIPS: AR71xx: Fix AR71XX_PCI_MEM_SIZE

2013-01-30T20:43:11Z

The base address of the PCI memory is 0x10000000 and the base address of the PCI configuration space is 0x17000000 on the AR71xx SoCs. The AR71XX_PCI_MEM_SIZE is defined as 0x08000000 which is wrong because that overlaps with the configuration space. This patch fixes the value of the AR71XX_PCI_MEM_SIZE constant, in order to avoid this resource conflicts. Signed-off-by: Gabor Juhos Patchwork: http://patchwork.linux-mips.org/patch/4873/ Signed-off-by: John Crispin Signed-off-by: Ralf Baechle

MIPS: AR724x: Fix AR724X_PCI_MEM_SIZE

2013-01-30T20:42:41Z

The base address of the PCI memory is 0x10000000 and the base address of the PCI configuration space is 0x14000000 on the AR724x SoCs. The AR724X_PCI_MEM_SIZE is defined as 0x08000000 which is wrong because that overlaps with the configuration space. The patch fixes the value of the AR724X_PCI_MEM_SIZE constant, in order to avoid this resource conflicts. Signed-off-by: Gabor Juhos Patchwork: http://patchwork.linux-mips.org/patch/4872/ Signed-off-by: John Crispin Signed-off-by: Ralf Baechle

MIPS: Lantiq: Fix cp0_perfcount_irq mapping

2013-01-30T20:28:28Z

The introduction of the OF support broke the cp0_perfcount_irq mapping. This resulted in oprofile not working anymore. Offending commit is : commit 3645da0276ae9f6938ff29b13904b803ecb68424 Author: John Crispin Date: Tue Apr 17 10:18:32 2012 +0200 OF: MIPS: lantiq: implement irq_domain support Signed-off-by: Conor O'Gorman Signed-off-by: John Crispin Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/4875/ Signed-off-by: Ralf Baechle

MIPS: DSP: Fix DSP mask for registers.

2013-01-24T12:20:09Z

The DSP bit mask for the RDDSP and WRDSP instructions was wrong. [ralf@linux-mips.org: The mask field of the RDDSP and WRDSP instructions is 10 bits long. DSP_MASK had all these fields which according to the architecture specification may result in UNPREDICTABLE operation.] Signed-off-by: Steven J. Hill Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/4683/ Signed-off-by: Ralf Baechle

MIPS: Fix build failure by adding definition of pfn_pmd().

2013-01-23T10:56:44Z

With CONFIG_TRANSPARENT_HUGEPAGE=y and CONFIG_HUGETLBFS=y we get the following build failure: CC mm/huge_memory.o mm/huge_memory.c: In function 'set_huge_zero_page': mm/huge_memory.c:780:2: error: implicit declaration of function 'pfn_pmd' [-Werror=implicit-function-declaration] mm/huge_memory.c:780:8: error: incompatible types when assigning to type 'pmd_t' from type 'int' Add a definition of pfn_pmd() for 64-bit kernels (the only place huge pages are currently supported). Signed-off-by: David Daney Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/4813/ Signed-off-by: Ralf Baechle

MIPS: Octeon: Fix warning.

2013-01-22T17:07:46Z

Cong Ding reports correctly that the variable dummy is being used without initialization. That said, I can't reproduce this warning with GCC 4.7.1. However, since the variable dummy servces no real purpose, I'm going for a different fix. This fix includes https://patchwork.linux-mips.org/patch/4801/ plus Geert's suggestion to use ACCESS_ONCE(). Signed-off-by: Ralf Baechle

MIPS: delay.c: Check BITS_PER_LONG instead of __SIZEOF_LONG__

2013-01-22T15:53:48Z

When building a 32-bit kernel for RBTX4927 with gcc version 4.1.2 20061115 (prerelease) (Ubuntu 4.1.1-21), I get: arch/mips/lib/delay.c:24:5: warning: "__SIZEOF_LONG__" is not defined As a consequence, __delay() always uses the 64-bit "dsubu" instruction. Replace the check for "__SIZEOF_LONG__ == 4" by "BITS_PER_LONG == 32" to fix this. Introduced by commit 5210edcd527773c227465ad18e416a894966324f [MIPS: Make __{,n,u}delay declarations match definitions and generic delay.h"] Signed-off-by: Geert Uytterhoeven Patchwork: https://patchwork.linux-mips.org/patch/4678/ Acked-by: David Daney Signed-off-by: Ralf Baechle