- 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:
Paul Burton <paul.burton@mips.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: David S. Miller <davem@davemloft.net> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Evgeniy Polyakov <zbr@ioremap.net> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: linux-input@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-serial@vger.kernel.org
-
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:Philippe Mathieu-Daudé <f4bug@amsat.org> 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:
Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: Yunqiang Su <ysu@wavecomp.com> Cc: stable@vger.kernel.org # v4.14+ 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 11 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:
-
Paul Cercueil authored
The default clock (12 MHz) is too fast for the system timer, which fails to report time accurately. Signed-off-by:
-
Paul Cercueil authored
Add DTS nodes for the JZ4780, JZ4770 and JZ4740 devicetree files. Signed-off-by:
-
Paul Cercueil authored
Add the missing TCU clock to the list of clocks supplied by the CGU for the JZ4740 SoC. Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Paul Cercueil authored
This driver handles the TCU (Timer Counter Unit) present on the Ingenic JZ47xx SoCs, and provides the kernel with a system timer, a clocksource and a sched_clock. Signed-off-by:
-
Paul Cercueil authored
This driver handles the interrupt controller built in the Timer/Counter Unit (TCU) of the JZ47xx SoCs from Ingenic. Signed-off-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
-
Paul Cercueil authored
Add driver to support the clocks provided by the Timer/Counter Unit (TCU) of the JZ47xx SoCs from Ingenic. Signed-off-by:
-
Paul Cercueil authored
device_node_to_regmap() is exactly like syscon_node_to_regmap(), but it does not check that the node is compatible with "syscon", and won't attach the first clock it finds to the regmap. The rationale behind this, is that one device node with a standard compatible string "foo,bar" can be covered by multiple drivers sharing a regmap, or by a single driver doing all the job without a regmap, but these are implementation details which shouldn't reflect on the devicetree. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
