- 03 Jan, 2020 1 commit
-
-
Paul Burton authored
Declaring __current_thread_info as a global register variable has the effect of preventing GCC from saving & restoring its value in cases where the ABI would typically do so. To quote GCC documentation: > If the register is a call-saved register, call ABI is affected: the > register will not be restored in function epilogue sequences after the > variable has been assigned. Therefore, functions cannot safely return > to callers that assume standard ABI. When our position independent VDSO is built for the n32 or n64 ABIs all functions it exposes should be preserving the value of $gp/$28 for their caller, but in the presence of the __current_thread_info global register variable GCC stops doing so & simply clobbers $gp/$28 when calculating the address of the GOT. In cases where the VDSO returns success this problem will typically be masked by the caller in libc returning & restoring $gp/$28 itself, but that is by no means guaranteed. In cases where the VDSO returns an error libc will typically contain a fallback path which will now fail (typically with a bad memory access) if it attempts anything which relies upon the value of $gp/$28 - eg. accessing anything via the GOT. One fix for this would be to move the declaration of __current_thread_info inside the current_thread_info() function, demoting it from global register variable to local register variable & avoiding inadvertently creating a non-standard calling ABI for the VDSO. Unfortunately this causes issues for clang, which doesn't support local register variables as pointed out by commit fe92da0f ("MIPS: Changed current_thread_info() to an equivalent supported by both clang and GCC") which introduced the global register variable before we had a VDSO to worry about. Instead, fix this by continuing to use the global register variable for the kernel proper but declare __current_thread_info as a simple extern variable when building the VDSO. It should never be referenced, and will cause a link error if it is. This resolves the calling convention issue for the VDSO without having any impact upon the build of the kernel itself for either clang or gcc. Signed-off-by:
Paul Burton <paulburton@kernel.org> Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO") Reported-by:
Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by:
-
- 18 Dec, 2019 3 commits
-
-
Alexander Lobakin authored
It is completely wrong to check for compile-time MIPS ISA revision in the body of bpf_int_jit_compile() as it may lead to get MIPS JIT fully omitted by the CC while the rest system will think that the JIT is actually present and works [1]. We can check if the selected CPU really supports MIPS eBPF JIT at configure time and avoid such situations when kernel can be built without both JIT and interpreter, but with CONFIG_BPF_SYSCALL=y. [1] https://lore.kernel.org/linux-mips/09d713a59665d745e21d021deeaebe0a@dlink.ru/ Fixes: 716850ab ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.") Cc: <stable@vger.kernel.org> # v5.2+ Signed-off-by:
Alexander Lobakin <alobakin@dlink.ru> Signed-off-by:
-
Paul Burton authored
Commit 716850ab ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.") enabled our eBPF JIT for MIPS32 kernels, whereas it has previously only been availailable for MIPS64. It was my understanding at the time that the BPF test suite was passing & JITing a comparable number of tests to our cBPF JIT [1], but it turns out that was not the case. The eBPF JIT has a number of problems on MIPS32: - Most notably various code paths still result in emission of MIPS64 instructions which will cause reserved instruction exceptions & kernel panics when run on MIPS32 CPUs. - The eBPF JIT doesn't account for differences between the O32 ABI used by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably arguments beyond the first 4 are passed on the stack in O32, and this is entirely unhandled when JITing a BPF_CALL instruction. Stack space must be reserved for arguments even if they all fit in registers, and the callee is free to assume that stack space has been reserved for its use - with the eBPF JIT this is not the case, so calling any function can result in clobbering values on the stack & unpredictable behaviour. Function arguments in eBPF are always 64-bit values which is also entirely unhandled - the JIT still uses a single (32-bit) register per argument. As a result all function arguments are always passed incorrectly when JITing a BPF_CALL instruction, leading to kernel crashes or strange behavior. - The JIT attempts to bail our on use of ALU64 instructions or 64-bit memory access instructions. The code doing this at the start of build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW, when it should really be checking BPF_SIZE() & only doing so when BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false positives that cause more bailouts than intended, and that in turns hides some of the problems described above. - The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF instructions that the MIPS32 eBPF JIT bails out on, leading to most cBPF programs not being JITed at all. Until these problems are resolved, revert the enabling of the eBPF JIT on MIPS32 done by commit 716850ab ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture."). Note that this does not undo the changes made to the eBPF JIT by that commit, since they are a useful starting point to providing MIPS32 support - they're just not nearly complete. [1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/Signed-off-by:
-
Jouni Hogander authored
__sanitizer_cov_trace_pc() is not linked in and causing link failure if KCOV_INSTRUMENT is enabled. Fix this by disabling instrumentation for compressed image. Signed-off-by:
Jouni Hogander <jouni.hogander@unikie.com> Signed-off-by:
-
- 02 Dec, 2019 2 commits
-
-
Joe Perches authored
Remove the CONFIG_ prefix from "depends on" as it makes the selection not possible. Signed-off-by:
Joe Perches <joe@perches.com> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by:
-
Vincenzo Frascino authored
The libc provides a discovery mechanism for vDSO library and its symbols. When a symbol is not exposed by the vDSOs the libc falls back on the system calls. With the introduction of the unified vDSO library on mips this behavior is not honored anymore by the kernel in the case of gettimeofday(). The issue has been noticed and reported due to a dhclient failure on the CI20 board: root@letux:~# dhclient ../../../../lib/isc/unix/time.c:200: Operation not permitted root@letux:~# Restore the original behavior fixing gettimeofday() in the vDSO library. Reported-by:
H. Nikolaus Schaller <hns@goldelico.com> Tested-by: H. Nikolaus Schaller <hns@goldelico.com> # CI20 with JZ4780 Signed-off-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by:
-
- 27 Nov, 2019 1 commit
-
-
Guenter Roeck authored
Commit 268a2d60 ("MIPS: Loongson64: Rename CPU TYPES") changed Kconfig symbols as follows: CPU_LOONGSON2 to CPU_LOONGSON2EF CPU_LOONGSON3 to CPU_LOONGSON64 SYS_HAS_CPU_LOONGSON3 to SYS_HAS_CPU_LOONGSON64 It did not touch SYS_HAS_CPU_LOONGSON2E or SYS_HAS_CPU_LOONGSON2F. However, the patch changed a conditional from #if defined(CONFIG_SYS_HAS_CPU_LOONGSON2E) || \ defined(CONFIG_SYS_HAS_CPU_LOONGSON2F) to #if defined(CONFIG_SYS_HAS_CPU_LOONGSON2EF) SYS_HAS_CPU_LOONGSON2EF does not exist, resulting in boot failures with the qemu fulong2e emulation. Revert to the original code. Fixes: 268a2d60 ("MIPS: Loongson64: Rename CPU TYPES") Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
-
- 26 Nov, 2019 1 commit
-
-
Vladimir Kondratiev authored
Report L1 caches as shared per core; L2 - per cluster. This fixes "perf" that went crazy if shared_cpu_map attribute not reported on sysfs, in form of /sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_list /sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_map Signed-off-by:
Vladimir Kondratiev <vladimir.kondratiev@intel.com> Signed-off-by:
-
- 23 Nov, 2019 2 commits
-
-
Thomas Bogendoerfer authored
PROM only enables ethernet PHY on first Origin 200 module, so we must do it ourselves for the second module. Signed-off-by:
Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by:
-
Thomas Bogendoerfer authored
Generation of fake subdevice ID had vendor and device ID swapped. Signed-off-by:
-
- 22 Nov, 2019 6 commits
-
-
Zhou Yanjie authored
JZ4760/JZ4770/JZ4775/X1000/X1500 has an abandoned huge page tlb, this mode is not compatible with the MIPS standard, it will cause tlbmiss and into an infinite loop (line 21 in the tlb-funcs.S) when starting the init process. write 0xa9000000 to cp0 register 5 sel 4 to disable this function to prevent getting stuck. Confirmed by Ingenic, this operation will not adversely affect processors without HPTLB function. Signed-off-by:
Zhou Yanjie <zhouyanjie@zoho.com> Acked-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Thomas Bogendoerfer authored
When changing interrupt affinity remember the possible changed nasid, otherwise an interrupt deactivate/activate sequence will incorrectly setup interrupt. Fixes: e6308b6d ("MIPS: SGI-IP27: abstract chipset irq from bridge") Signed-off-by:
-
Thomas Bogendoerfer authored
If number of CPUs are limited by the kernel commandline parameter nr_cpus assignment of interrupts accourding to numa rules might not be possibe. As a fallback use one of the online CPUs as interrupt destination. Fixes: 69a07a41 ("MIPS: SGI-IP27: rework HUB interrupts") Signed-off-by:
-
Mike Rapoport authored
Implement primitives necessary for the 4th level folding, add walks of p4d level where appropriate, replace 5leve-fixup.h with pgtable-nop4d.h and drop usage of __ARCH_USE_5LEVEL_HACK. Signed-off-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
-
Mike Rapoport authored
The __pXd_offset() macros are identical to the pXd_index() macros and there is no point to keep both of them. All architectures define and use pXd_index() so let's keep only those to make mips consistent with the rest of the kernel. Signed-off-by:
-
Mike Rapoport authored
With CONFIG_MIPS_VA_BITS_48=y the build fails miserably: CC arch/mips/kernel/asm-offsets.s In file included from arch/mips/include/asm/pgtable.h:644, from include/linux/mm.h:99, from arch/mips/kernel/asm-offsets.c:15: include/asm-generic/pgtable.h:16:2: error: #error CONFIG_PGTABLE_LEVELS is not consistent with __PAGETABLE_{P4D,PUD,PMD}_FOLDED #error CONFIG_PGTABLE_LEVELS is not consistent with __PAGETABLE_{P4D,PUD,PMD}_FOLDED ^~~~~ include/asm-generic/pgtable.h:390:28: error: unknown type name 'p4d_t'; did you mean 'pmd_t'? static inline int p4d_same(p4d_t p4d_a, p4d_t p4d_b) ^~~~~ pmd_t [ ... more such errors ... ] scripts/Makefile.build:99: recipe for target 'arch/mips/kernel/asm-offsets.s' failed make[2]: *** [arch/mips/kernel/asm-offsets.s] Error 1 This happens because when CONFIG_MIPS_VA_BITS_48 enables 4th level of the page tables, but neither pgtable-nop4d.h nor 5level-fixup.h are included to cope with the 5th level. Replace #ifdef conditions around includes of the pgtable-nop{m,u}d.h with explicit CONFIG_PGTABLE_LEVELS and add include of 5level-fixup.h for the case when CONFIG_PGTABLE_LEVELS==4 Signed-off-by:
-
- 11 Nov, 2019 9 commits
-
-
Paul Burton authored
The FPU_STAT_CREATE_EX() macro used 114 times in debugfs_fpuemu() declares a 32 byte char array to hold the name of a debugfs file. Since each use of the macro declares a new char array out of the scope of all the other uses, we end up with an unnecessarily large stack frame of 3648 bytes (ie. 114*32) plus the size of 2 pointers (fpuemu_debugfs_base_dir & fpuemu_debugfs_inst_dir). This is enough to trigger the frame size warnings from GCC in common configurations. Avoid the unnecessary stack bloat by using a single name char array which each usage of FPU_STAT_CREATE_EX() will reinitialize via the strcpy() in adjust_instruction_counter_name(). Signed-off-by:
kbuild test robot <lkp@intel.com> URL: https://lore.kernel.org/linux-mips/201911090929.xvXYuHUz%25lkp@intel.com/
-
Alexey Khoroshilov authored
Add ARCH_HAS_KCOV and HAVE_GCC_PLUGINS to MIPS config. Disable instrumentation of vdso to avoid build failure. Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Jiaxun Yang authored
setup_pcimap is used to setup address windows for Loongson-3 built-in PCI-X controller, but this function is never been used in the real world and lack of support in kernel. Signed-off-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by:
-
Jiaxun Yang authored
early_printk.c is doing the same with early_printk_8250. Remove duplicated code. Signed-off-by:
-
Jiaxun Yang authored
CPU_SUPPORTS_UNCACHED_ACCELERATED was introduced when kernel can't handle writecombine remap well. Nowadays drivers can try writecombine remap by themselves so this function is nolonger needed. Signed-off-by:
-
Jiaxun Yang authored
All of Loongson firmwares are passing boot cmdline/env in the manner of YAMON/PMON. Thus we can remove duplicated cmdline initialize code and convert to generic fw method. Signed-off-by:
-
Jiaxun Yang authored
There is no code still using pmon callvectors. Signed-off-by:
-
Huacai Chen authored
There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's establish some rules: 1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since they all not widely-used symbols and sometimes not suitable for all 64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT, CPU_LOONGSON3_WORKAROUNDS, etc. 2, Hide GSx64/GSx64E in Kconfig title since it is not useful for general users. However, in the full description we use a more detailed manner. E.g., GS264/GS464/GS464E/GS464V. All Kconfig titles and descriptions of Loongson processors and machines have also been updated in this patch for consistency. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
-
Huacai Chen authored
Now old Loongson-2E/2F use LOONGSON2EF and will be removed in future, newer Loongson-2/3 use LOONGSON64. So rename LOONGSON1 to LOONGSON32 will make the naming style more unified. Signed-off-by:
-
- 04 Nov, 2019 1 commit
-
-
Tiezhu Yang authored
When call function hwmon_device_register failed, use the actual return value instead of always -ENOMEM. Fixes: 64f09aa9 ("MIPS: Loongson-3: Add CPU Hwmon platform driver") Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
-
- 01 Nov, 2019 10 commits
-
-
Thomas Bogendoerfer authored
This changeset adds support for SGI Octane/Octane2 workstations. Signed-off-by:
-
Thomas Bogendoerfer authored
All platforms using pci-xtalk-bridge can share common phys_to_dma/ dma_to_phys function. So we move it form ip27 specific file to pci-xtalk-bridge.c Signed-off-by:
-
Paul Burton authored
Pull in mips-fixes primarily to gain build fixes in order to allow better testing of mips-next. A few MIPS fixes: - Fix VDSO time-related function behavior for systems where we need to fall back to syscalls, but were instead returning bogus results. - A fix to TLB exception handlers for Cavium Octeon systems where they would inadvertently clobber the $1/$at register. - A build fix for bcm63xx configurations. - Switch to using my @kernel.org email address. Signed-off-by: -
Tiezhu Yang authored
When I update kernel with loongson3_defconfig based on the Loongson 3A3000 platform, then using dmesg command to show kernel ring buffer, the initial kernel messages have disappeared due to the log buffer is too small, it is better to change the kernel log buffer size from 16KB to 128KB which is enough to save the boot messages. Since the default LOG_BUF_SHIFT value is 17, the default kernel log buffer size is 128KB, just delete the CONFIG_LOG_BUF_SHIFT line. Signed-off-by:
-
Thomas Bogendoerfer authored
MAX_COMPACT_NODE is a leftover from the compact node implementation, which is removed now. Use MAX_NUMNODES instead. Signed-off-by:
-
Paul Menzel authored
Fixes: 5b3b1688 ("MIPS: Add Cavium OCTEON processor support files to arch/mips/cavium-octeon.") Signed-off-by:
Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by:
-
Jiaxun Yang authored
Current Loongson-3 code can share among all Loongson64 processors. Signed-off-by:
-
Jiaxun Yang authored
Clean up legacy code after stripping out Loongson2ef code. Signed-off-by:
-
Jiaxun Yang authored
Remove unrelevent macros, defines and codes from loongson2ef mach. Also rename some defines to match new naming. Signed-off-by:
-
Jiaxun Yang authored
As later model of GSx64 family processors including 2-series-soc have similar design with initial loongson3a while loongson2e/f seems less identical, we separate loongson2e/f support code out of mach-loongson64 to make our life easier. This patch contains mostly file moving works. Signed-off-by:
-
- 31 Oct, 2019 1 commit
-
-
Jiaxun Yang authored
CPU_LOONGSON2 -> CPU_LOONGSON2EF CPU_LOONGSON3 -> CPU_LOONGSON64 As newer loongson-2 products (2G/2H/2K1000) can share kernel implementation with loongson-3 while 2E/2F are less similar with other LOONGSON64 products. Signed-off-by:
-
- 24 Oct, 2019 3 commits
-
-
Thomas Bogendoerfer authored
asm/sgi/sgi.h is unused, time to remove it. Signed-off-by:
-
Paul Burton authored
build_restore_pagemask() will restore the value of register $1/$at when its restore_scratch argument is non-zero, and aims to do so by filling a branch delay slot. Commit 0b24cae4 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.") added an EHB instruction (Execution Hazard Barrier) prior to restoring $1 from a KScratch register, in order to resolve a hazard that can result in stale values of the KScratch register being observed. In particular, P-class CPUs from MIPS with out of order execution pipelines such as the P5600 & P6600 are affected. Unfortunately this EHB instruction was inserted in the branch delay slot causing the MFC0 instruction which performs the restoration to no longer execute along with the branch. The result is that the $1 register isn't actually restored, ie. the TLB refill exception handler clobbers it - which is exactly the problem the EHB is meant to avoid for the P-class CPUs. Similarly build_get_pgd_vmalloc() will restore the value of $1/$at when its mode argument equals refill_scratch, and suffers from the same problem. Fix this by in both cases moving the EHB earlier in the emitted code. There's no reason it needs to immediately precede the MFC0 - it simply needs to be between the MTC0 & MFC0. This bug only affects Cavium Octeon systems which use build_fast_tlb_refill_handler(). Signed-off-by:
-
Thomas Bogendoerfer authored
IP27 uses ARC prom only for parsing prom arguments and has a hack for IP27 to make the ARC code behave. By introducing config symbol ARC_CMDLINE_ONLY IP27 only drags in ARC cmdline parsing and does everything else in IP27 specific code. Signed-off-by:
-
