- 20 Sep, 2019 1 commit
-
-
Paul Burton authored
Commit 61cbfff4 ("MIPS: pte_special()/pte_mkspecial() support") added a _PAGE_SPECIAL bit to the pgprot bits of our PTEs. Unfortunately for MIPS32 configurations with RiXi support this pushed the number of pgprot bits to 13. Since the PFN field in EntryLo begins at bit 12 this results in us shifting the most significant bit of the physical address beyond the end of the PTE, leading any mapped access to a physical address above 2GB to incorrectly access an address 2GB lower than intended. For now, disable the pte_special() support for MIPS32 configurations that support RiXi. Fixes: 61cbfff4 ("MIPS: pte_special()/pte_mkspecial() support") Signed-off-by:
Paul Burton <paul.burton@mips.com> Cc: Dmitry Korotin <dkorotin@wavecomp.com> Cc: linux-mips@vger.kernel.org
-
- 06 Sep, 2019 1 commit
-
-
Hauke Mehrtens authored
The Linux does not support PCI on the SOC_MT7621, if it is selected the Linux build runs into a compile error. Remove HAVE_PCI from the SOC_MT7621 SoC. Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
- 03 Sep, 2019 5 commits
-
-
Vincenzo Frascino authored
The generic VDSO implementation uses the Y2038 safe clock_gettime64() and clock_getres_time64() syscalls as fallback for 32bit VDSO. This breaks seccomp setups because these syscalls might be not (yet) allowed. Implement the 32bit variants which use the legacy syscalls and select the variant in the core library. The 64bit time variants are not removed because they are required for the time64 based vdso accessors. Cc: Paul Burton <paul.burton@mips.com> Fixes: 00b26474 ("lib/vdso: Provide generic VDSO implementation") Signed-off-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by:
-
Paul Burton authored
_CACHE_CACHABLE_NONCOHERENT is defined as 3<<_CACHE_SHIFT by default, so there's no need to define it as such specifically for Loongson. _CACHE_CACHABLE_COHERENT is not used anywhere in the kernel, so there's no need to define it at all. Finally the comment found alongside these definitions seems incorrect - it suggests that we're defining _CACHE_CACHABLE_NONCOHERENT such that it actually provides coherence, but the opposite seems to be true & instead the unused _CACHE_CACHABLE_COHERENT is defined as the typically incoherent value. Delete the whole thing, which will have no effect on the compiled code anyway. Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: linux-mips@vger.kernel.org
-
Paul Burton authored
The cpu_has_local_ebase macro is, confusingly, not used to indicate whether the EBase register is local to a CPU or not. Instead it indicates whether we want to generate the TLB refill exception vector each time a CPU is brought online. Doing this makes little sense on any system, since we always use the same value for EBase & thus we cannot have different TLB refill exception handlers per CPU. Regenerating the code is not only pointless but also can be actively harmful, as commit 8759934e ("MIPS: Build uasm-generated code only once to avoid CPU Hotplug problem") described. That commit introduced cpu_has_local_ebase to disable the handler regeneration for Loongson machines, but this is by no means a Loongson-specific problem. Remove cpu_has_local_ebase & simply generate the TLB refill handler once during boot, just like the rest of the TLB exception handlers. Signed-off-by:
-
Paul Burton authored
We already know whether a CPU has r3k style exceptions, including TLB exceptions, by checking cpu_has_3kex. Remove the list of CPU types in build_tlb_refill_handler() & check cpu_has_3kex instead. Signed-off-by: -
Paul Burton authored
Currently areas where we need to determine whether the TLB is R3k-style need to check for either of CONFIG_CPU_R3000 || CONFIG_CPU_TX39XX. Introduce a new CONFIG_CPU_R3K_TLB & select it from both of the above, allowing us to simplify checks for R3k-style TLBs by only checking for this new Kconfig option. Signed-off-by:
-
- 31 Aug, 2019 5 commits
-
-
Thomas Bogendoerfer authored
Refactored code to only have one ioc3 special handling for read access and one for write access. Signed-off-by:
Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by:
-
Christoph Hellwig authored
Just define ioremap_cache directly. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Peter Zijlstra authored
Recent probing at the Linux Kernel Memory Model uncovered a 'surprise'. Strongly ordered architectures where the atomic RmW primitive implies full memory ordering and smp_mb__{before,after}_atomic() are a simple barrier() (such as MIPS without WEAK_REORDERING_BEYOND_LLSC) fail for: *x = 1; atomic_inc(u); smp_mb__after_atomic(); r0 = *y; Because, while the atomic_inc() implies memory order, it (surprisingly) does not provide a compiler barrier. This then allows the compiler to re-order like so: atomic_inc(u); *x = 1; smp_mb__after_atomic(); r0 = *y; Which the CPU is then allowed to re-order (under TSO rules) like: atomic_inc(u); r0 = *y; *x = 1; And this very much was not intended. Therefore strengthen the atomic RmW ops to include a compiler barrier. Reported-by:Andrea Parri <andrea.parri@amarulasolutions.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
-
Peter Zijlstra authored
The comment describing the loongson_llsc_mb() reorder case doesn't make any sense what so ever. Instruction re-ordering is not an SMP artifact, but rather a CPU local phenomenon. Clarify the comment by explaining that these issue cause a coherence fail. For the branch speculation case; if futex_atomic_cmpxchg_inatomic() needs one at the bne branch target, then surely the normal __cmpxch_asm() implementation does too. We cannot rely on the barriers from cmpxchg() because cmpxchg_local() is implemented with the same macro, and branch prediction and speculation are, too, CPU local. Fixes: e02e07e3 ("MIPS: Loongson: Introduce and use loongson_llsc_mb()") Cc: Huacai Chen <chenhc@lemote.com> Cc: Huang Pei <huangpei@loongson.cn> Signed-off-by:
-
Peter Zijlstra authored
There were no memory barriers on the 32bit implementation of cmpxchg64(). Fix this. Signed-off-by:
-
- 27 Aug, 2019 1 commit
-
-
YueHaibing authored
Remove duplicated include. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
- 26 Aug, 2019 4 commits
-
-
Florian Fainelli authored
Allow building building the BCM47xx NVRAM and SPROM drivers using COMPILE_TEST. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
When building on a 64-bit host, we will get warnings like those: drivers/firmware/broadcom/bcm47xx_nvram.c:103:3: note: in expansion of macro 'pr_err' pr_err("nvram on flash (%i bytes) is bigger than the reserved space in memory, will just copy the first %i bytes\n", ^~~~~~ drivers/firmware/broadcom/bcm47xx_nvram.c:103:28: note: format string is defined here pr_err("nvram on flash (%i bytes) is bigger than the reserved space in memory, will just copy the first %i bytes\n", ~^ %li Use %zu instead for that purpose. Signed-off-by: -
Jiaxun Yang authored
Recently, binutils had split Loongson-3 Extensions into four ASEs: MMI, CAM, EXT, EXT2. This patch do the samething in kernel and expose them in cpuinfo so applications can probe supported ASEs at runtime. Signed-off-by:
-
Stephen Boyd authored
We don't need dev_err() messages when platform_get_irq() fails now that platform_get_irq() prints an error message itself when something goes wrong. Let's remove these prints with a simple semantic patch. // <smpl> @@ expression ret; struct platform_device *E; @@ ret = ( platform_get_irq(E, ...) | platform_get_irq_byname(E, ...) ); if ( \( ret < 0 \| ret <= 0 \) ) { ( -if (ret != -EPROBE_DEFER) -{ ... -dev_err(...); -... } | ... -dev_err(...); ) ... } // </smpl> While we're here, remove braces on if statements that only have one statement (manually). Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@mips.com> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
- 24 Aug, 2019 4 commits
-
-
Antoine Tenart authored
This patch adds a description of the PTP ready interrupt, which can be triggered when a PTP timestamp is available on an hardware FIFO. Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
-
Antoine Tenart authored
This patch adds one register range within the mscc,vsc7514-switch node, to describe the PTP registers. Signed-off-by:
-
Martin Blumenstingl authored
The mainline PCIe PHY driver has it's own devicetree node. Update the clock alias so the mainline driver finds the clocks. The first PCIe PHY is located at 0x1f106800 and exists on VRX200, ARX300 and GRX390. The second PCIe PHY is located at 0x1f700400 and exists on ARX300 and GRX390. The third PCIe PHY is located at 0x1f106a00 and exists onl on GRX390. Lantiq's board support package (called "UGW") names these registers "PDI". Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Nick Desaulniers authored
The code in question is modifying a variable declared const through pointer manipulation. Such code is explicitly undefined behavior, and is the lone issue preventing malta_defconfig from booting when built with Clang: If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined. LLVM is removing such assignments. A simple fix is to not declare variables const that you plan on modifying. Limiting the scope would be a better method of preventing unwanted writes to such a variable. Further, the code in question mentions "compiler bugs" without any links to bug reports, so it is difficult to know if the issue is resolved in GCC. The patch was authored in 2006, which would have been GCC 4.0.3 or 4.1.1. The minimal supported version of GCC in the Linux kernel is currently 4.6. For what its worth, there was UB before the commit in question, it just added a barrier and got lucky IRT codegen. I don't think there's any actual compiler bugs related, just runtime bugs due to UB. Link: https://github.com/ClangBuiltLinux/linux/issues/610 Fixes: 966f4406 ("[MIPS] Work around bad code generation for <asm/io.h>.") Reported-by:
Nathan Chancellor <natechancellor@gmail.com> Debugged-by:
Eli Friedman <efriedma@quicinc.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
-
- 23 Aug, 2019 10 commits
-
-
Paul Burton authored
Commit a94e4f24 ("MIPS: init: Drop boot_mem_map") introduced a reference to a non-existant "end" field in struct memblock_region. Replace it with a sum of the base & size fields to fix builds with CONFIG_PROC_VMCORE=y. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
Paul Burton authored
Commit a5718fe8 ("MIPS: mm: Drop boot_mem_map") removed the definition of a page variable for some reason, but that variable is still used. Restore it to fix compilation with CONFIG_HIGHMEM enabled. Signed-off-by:
-
Jiaxun Yang authored
boot_mem_map was introduced very early and cannot handle memory maps with nid. Nowadays, memblock can exactly replace boot_mem_map. Detect pfn info and setup resources with memblock maps. Signed-off-by:
-
Jiaxun Yang authored
Initialize maar by resource map and replace page_is_ram by memblock_is_memory. Signed-off-by:
-
Jiaxun Yang authored
Simply replace with memblock functions. Signed-off-by:
-
Jiaxun Yang authored
It can be replaced by page_is_ram. Signed-off-by:
-
Jiaxun Yang authored
boot_mem_map is nolonger exist so we need to maintain a list of prom memory by ourselves Signed-off-by:
-
Jiaxun Yang authored
Current prom_free_prom_memory is freeing maps marked as BOOT_MEM_ROM_DATA, however, nobody is exactly setting this type for malta. Signed-off-by:
-
Jiaxun Yang authored
boot_mem_map is nolonger exist so we need to maintain a list of prom memory by ourselves. Signed-off-by:
-
Jiaxun Yang authored
Replace walk through boot_mem_map with for_each_memblock. And remove the check of total boot_mem_map. Signed-off-by:
-
- 19 Aug, 2019 2 commits
-
-
YueHaibing authored
While do COMPILE_TEST building, if GENERIC_IRQ_CHIP is not selected, it fails: drivers/irqchip/irq-ingenic-tcu.o: In function `ingenic_tcu_intc_cascade': irq-ingenic-tcu.c:(.text+0x13f): undefined reference to `irq_get_domain_generic_chip' drivers/irqchip/irq-ingenic-tcu.o: In function `ingenic_tcu_irq_init': irq-ingenic-tcu.c:(.init.text+0x97): undefined reference to `irq_generic_chip_ops' irq-ingenic-tcu.c:(.init.text+0xdd): undefined reference to `__irq_alloc_domain_generic_chips' irq-ingenic-tcu.c:(.init.text+0x10b): undefined reference to `irq_get_domain_generic_chip' select GENERIC_IRQ_CHIP to fix this. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 9536eba0 ("irqchip: Add irq-ingenic-tcu driver") Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Christophe JAILLET authored
It should be OCTEON_SERIAL_LEN. Update the #define and use it accordingly Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
- 12 Aug, 2019 3 commits
-
-
Nathan Chancellor authored
clang warns: arch/mips/mm/tlbex.c:634:19: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if (cpu_has_rixi && _PAGE_NO_EXEC) { ^ ~~~~~~~~~~~~~ arch/mips/mm/tlbex.c:634:19: note: use '&' for a bitwise operation if (cpu_has_rixi && _PAGE_NO_EXEC) { ^~ & arch/mips/mm/tlbex.c:634:19: note: remove constant to silence this warning if (cpu_has_rixi && _PAGE_NO_EXEC) { ~^~~~~~~~~~~~~~~~ 1 error generated. Explicitly cast this value to a boolean so that clang understands we intend for this to be a non-zero value. Fixes: 00bf1c69 ("MIPS: tlbex: Avoid placing software PTE bits in Entry* PFN fields") Link: https://github.com/ClangBuiltLinux/linux/issues/609Signed-off-by: -
Nathan Chancellor authored
clang warns: arch/mips/include/asm/syscall.h:136:3: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized] ret |= mips_get_syscall_arg(args++, task, regs, i++); ^~~ arch/mips/include/asm/syscall.h:129:9: note: initialize the variable 'ret' to silence this warning int ret; ^ = 0 1 error generated. It's not wrong; however, it's not an issue in practice because ret is only assigned to, not read from. ret could just be initialized to zero but looking into it further, ret has been unused since it was first added in 2012 so just get rid of it and update mips_get_syscall_arg's return type since none of the return values are ever checked. If it is ever needed again, this commit can be reverted and ret can be properly initialized. Fixes: c0ff3c53 ("MIPS: Enable HAVE_ARCH_TRACEHOOK.") Link: https://github.com/ClangBuiltLinux/linux/issues/604Signed-off-by: -
Nathan Chancellor authored
clang warns: arch/mips/kernel/branch.c:148:8: error: variable 'bc_false' is used uninitialized whenever switch case is taken [-Werror,-Wsometimes-uninitialized] case mm_bc2t_op: ^~~~~~~~~~ arch/mips/kernel/branch.c:157:8: note: uninitialized use occurs here if (bc_false) ^~~~~~~~ arch/mips/kernel/branch.c:149:8: error: variable 'bc_false' is used uninitialized whenever switch case is taken [-Werror,-Wsometimes-uninitialized] case mm_bc1t_op: ^~~~~~~~~~ arch/mips/kernel/branch.c:157:8: note: uninitialized use occurs here if (bc_false) ^~~~~~~~ arch/mips/kernel/branch.c:142:4: note: variable 'bc_false' is declared here int bc_false = 0; ^ 2 errors generated. When mm_bc1t_op and mm_bc2t_op are taken, the bc_false initialization does not happen, which leads to a garbage value upon use, as illustrated below with a small sample program. $ mipsel-linux-gnu-gcc --version | head -n1 mipsel-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0 $ clang --version | head -n1 ClangBuiltLinux clang version 9.0.0 (git://github.com/llvm/llvm-project 544315b4197034a3be8acd12cba56a75fb1f08dc) (based on LLVM 9.0.0svn) $ cat test.c #include <stdio.h> static void switch_scoped(int opcode) { switch (opcode) { case 1: case 2: { int bc_false = 0; bc_false = 4; case 3: case 4: printf("\t* switch scoped bc_false = %d\n", bc_false); } } } static void function_scoped(int opcode) { int bc_false = 0; switch (opcode) { case 1: case 2: { bc_false = 4; case 3: case 4: printf("\t* function scoped bc_false = %d\n", bc_false); } } } int main(void) { int opcode; for (opcode = 1; opcode < 5; opcode++) { printf("opcode = %d:\n", opcode); switch_scoped(opcode); function_scoped(opcode); printf("\n"); } return 0; } $ mipsel-linux-gnu-gcc -std=gnu89 -static test.c && \ qemu-mipsel a.out opcode = 1: * switch scoped bc_false = 4 * function scoped bc_false = 4 opcode = 2: * switch scoped bc_false = 4 * function scoped bc_false = 4 opcode = 3: * switch scoped bc_false = 2147483004 * function scoped bc_false = 0 opcode = 4: * switch scoped bc_false = 2147483004 * function scoped bc_false = 0 $ clang -std=gnu89 --target=mipsel-linux-gnu -m32 -static test.c && \ qemu-mipsel a.out opcode = 1: * switch scoped bc_false = 4 * function scoped bc_false = 4 opcode = 2: * switch scoped bc_false = 4 * function scoped bc_false = 4 opcode = 3: * switch scoped bc_false = 2147483004 * function scoped bc_false = 0 opcode = 4: * switch scoped bc_false = 2147483004 * function scoped bc_false = 0 Move the definition up so that we get the right behavior and mark it __maybe_unused as it will not be used when CONFIG_MIPS_FP_SUPPORT isn't enabled. Fixes: 6a1cc218 ("MIPS: branch: Remove FP branch handling when CONFIG_MIPS_FP_SUPPORT=n") Link: https://github.com/ClangBuiltLinux/linux/issues/603Signed-off-by:
-
- 08 Aug, 2019 4 commits
-
-
Paul Burton authored
Merge the Ingenic TCU patchset from the ingenic-tcu-v5.4 branch which was created to enable follow-on changes in other subsystems. Signed-off-by: -
Paul Cercueil authored
The old clocksource/timer platform code is now obsoleted by the newly introduced TCU drivers. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Tested-by:
Mathieu Malaterre <malat@debian.org> Tested-by:
Artur Rojek <contact@artur-rojek.eu> Signed-off-by:
-
Paul Cercueil authored
The default clock (12 MHz) is too fast for the system timer. Signed-off-by:
-
Paul Cercueil authored
The default clock (48 MHz) is too fast for the system timer. Signed-off-by:
-
