- 24 Jul, 2018 2 commits
-
-
Huacai Chen authored
Loongson-3A R3.1 is the bugfix revision of Loongson-3A R3. All Loongson-3 CPU family: Code-name Brand-name PRId Loongson-3A R1 Loongson-3A1000 0x6305 Loongson-3A R2 Loongson-3A2000 0x6308 Loongson-3A R3 Loongson-3A3000 0x6309 Loongson-3A R3.1 Loongson-3A3000 0x630d Loongson-3B R1 Loongson-3B1000 0x6306 Loongson-3B R2 Loongson-3B1500 0x6307 Signed-off-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/19263/ Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <james.hogan@mips.com> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: Huacai Chen <chenhuacai@gmail.com>
-
Paul Cercueil authored
Having the zload address at 0x8060.0000 means the size of the uncompressed kernel cannot be bigger than around 6 MiB, as it is deflated at address 0x8001.0000. This limit is too small; a kernel with some built-in drivers and things like debugfs enabled will already be over 6 MiB in size, and so will fail to extract properly. To fix this, we bump the zload address from 0x8060.0000 to 0x8100.0000. This is fine, as all the boards featuring Ingenic JZ SoCs have at least 32 MiB of RAM, and use u-boot or compatible bootloaders which won't hardcode the load address but read it from the uImage's header. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
- 23 Jul, 2018 2 commits
-
-
Hauke Mehrtens authored
Instead of using dma_alloc_coherent() and memset() directly use dma_zalloc_coherent(). Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Huacai Chen authored
Linux expects that if a CPU modifies a memory location, then that modification will eventually become visible to other CPUs in the system. Loongson 3 CPUs include a Store Fill Buffer (SFB) which sits between a core & its L1 data cache, queueing memory accesses & allowing for faster forwarding of data from pending stores to younger loads from the core. Unfortunately the SFB prioritizes loads such that a continuous stream of loads may cause a pending write to be buffered indefinitely. This is problematic if we end up with 2 CPUs which each perform a store that the other polls for - one or both CPUs may end up with their stores buffered in the SFB, never reaching cache due to the continuous reads from the poll loop. Such a deadlock condition has been observed whilst running qspinlock code. This patch changes the definition of cpu_relax() to smp_mb() for Loongson-3, forcing a flush of the SFB on SMP systems which will cause any pending writes to make it as far as the L1 caches where they will become visible to other CPUs. If the kernel is not compiled for SMP support, this will expand to a barrier() as before. This workaround matches that currently implemented for ARM when CONFIG_ARM_ERRATA_754327=y, which was introduced by commit 534be1d5 ("ARM: 6194/1: change definition of cpu_relax() for ARM11MPCore"). Although the workaround is only required when the Loongson 3 SFB functionality is enabled, and we only began explicitly enabling that functionality in v4.7 with commit 1e820da3 ("MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT"), existing or future firmware may enable the SFB which means we may need the workaround backported to earlier kernels too. [paul.burton@mips.com: - Reword commit message & comment. - Limit stable backport to v3.15+ where we support Loongson 3 CPUs.] Signed-off-by:
-
- 20 Jul, 2018 1 commit
-
-
Serge Semin authored
This macro substitution is the shortcut to map cacheable IO memory with coherent and write-back attributes. Since it is entirely unused by kernel, lets just remove it. Signed-off-by:
Serge Semin <fancer.lancer@gmail.com> Signed-off-by:
Christoph Hellwig <hch@infradead.org> Patchwork: https://patchwork.linux-mips.org/patch/19937/ CC: Paul Burton <paul.burton@mips.com> Cc: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Sinan Kaya <okaya@codeaurora.org> Cc: Huacai Chen <chenhc@lemote.com> Cc: Sergey.Semin@t-platforms.ru Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org
-
- 19 Jul, 2018 4 commits
-
-
Maciej W. Rozycki authored
Define an NT_MIPS_FP_MODE core file note and implement a corresponding regset holding the state handled by PR_SET_FP_MODE and PR_GET_FP_MODE prctl(2) requests. This lets debug software correctly interpret the contents of floating-point general registers both in live debugging and in core files, and also switch floating-point modes of a live process. [paul.burton@mips.com: - Changed NT_MIPS_FP_MODE to 0x801 to match first nibble of NT_MIPS_DSP, which was also changed to avoid a conflict.] Signed-off-by:Maciej W. Rozycki <macro@mips.com> Signed-off-by:
-
Maciej W. Rozycki authored
Define an NT_MIPS_DSP core file note type and implement a corresponding regset holding the DSP ASE register context, following the layout of the `mips_dsp_state' structure, except for the DSPControl register stored as a 64-bit rather than 32-bit quantity in a 64-bit note. The lack of DSP ASE register saving to core files can be considered a design flaw with commit e50c0a8f ("Support the MIPS32 / MIPS64 DSP ASE."), leading to an incomplete state being saved. Consequently no DSP ASE regset has been created with commit 7aeb753b ("MIPS: Implement task_user_regset_view."), when regset support was added to the MIPS port. Additionally there is no way for ptrace(2) to correctly access the DSP accumulator registers in n32 processes with the existing interfaces. This is due to 32-bit truncation of data passed with PTRACE_PEEKUSR and PTRACE_POKEUSR requests, which cannot be avoided owing to how the data types for ptrace(3) have been defined. This new NT_MIPS_DSP regset fills the missing interface gap. [paul.burton@mips.com: - Change NT_MIPS_DSP to 0x800 to avoid conflict with NT_VMCOREDD introduced by commit 2724273e ("vmcore: add API to collect hardware dump in second kernel"). - Drop stable tag. Whilst I agree the lack of this functionality can be considered a flaw in earlier DSP ASE support, it's still new functionality which doesn't meet up to the requirements set out in Documentation/process/stable-kernel-rules.rst.] Signed-off-by:
-
Maciej W. Rozycki authored
Use the `unsigned long' rather than `__u32' type for DSP accumulator registers, like with the regular MIPS multiply/divide accumulator and general-purpose registers, as all are 64-bit in 64-bit implementations and using a 32-bit data type leads to contents truncation on context saving. Update `arch_ptrace' and `compat_arch_ptrace' accordingly, removing casts that are similarly not used with multiply/divide accumulator or general-purpose register accesses. Signed-off-by:
-
Maciej W. Rozycki authored
The regset API documented in <linux/regset.h> defines -ENODEV as the result of the `->active' handler to be used where the feature requested is not available on the hardware found. However code handling core file note generation in `fill_thread_core_info' interpretes any non-zero result from the `->active' handler as the regset requested being active. Consequently processing continues (and hopefully gracefully fails later on) rather than being abandoned right away for the regset requested. Fix the problem then by making the code proceed only if a positive result is returned from the `->active' handler. Signed-off-by:
-
- 17 Jul, 2018 2 commits
-
-
Paul Burton authored
The PCI_OHCI_INT_REG case in pci_ohci_read_reg() contains the following if statement: if ((lo & 0x00000f00) == CS5536_USB_INTR) CS5536_USB_INTR expands to the constant 11, which gives us the following condition which can never evaluate true: if ((lo & 0xf00) == 11) At least when using GCC 8.1.0 this falls foul of the tautoligcal-compare warning, and since the code is built with the -Werror flag the build fails. Fix this by shifting lo right by 8 bits in order to match the corresponding PCI_OHCI_INT_REG case in pci_ohci_write_reg(). Signed-off-by:
-
Alexander Sverdlin authored
prom_putchar() is used centrally in early printk infrastructure therefore at least MIPS should agree on the function return type. [paul.burton@mips.com: - Include linux/types.h in asm/setup.h to gain the bool typedef before we start include asm/setup.h elsewhere. - Include asm/setup.h in all files that use or define prom_putchar(). - Also standardise on signed rather than unsigned char argument.] Signed-off-by:Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by:
-
- 12 Jul, 2018 3 commits
-
-
Joshua Kinard authored
This patch reduces down the conditionals in MIPS atomic code that deal with a silicon bug in early R10000 cpus that required a workaround of a branch-likely instruction following a store-conditional in order to to guarantee the whole ll/sc sequence is atomic. As the only real difference is a branch-likely instruction (beqzl) over a standard branch (beqz), the conditional is reduced down to a single preprocessor check at the top to pick the required instruction. This requires writing the uses in assembler, thus we discard the non-R10000 case that uses a mixture of a C do...while loop with embedded assembler that was added back in commit 7837314d ("MIPS: Get rid of branches to .subsections."). A note found in the git log for commit 5999eca25c1f ("[MIPS] Improve branch prediction in ll/sc atomic operations.") is also addressed. The macro definition for the branch instruction and the code comment derives from a patch sent in earlier by Paul Burton for various cmpxchg cleanups. [paul.burton@mips.com: - Minor whitespace fix for checkpatch.] Signed-off-by:
Joshua Kinard <kumba@gentoo.org> Signed-off-by:
-
Joshua Kinard authored
This patch fixes an old bug in MIPS ll/sc atomics, in the `atomic_sub_if_positive' and `atomic64_sub_if_positive' functions, for the R10000_LLSC_WAR case where the result of the subu/dsubu instruction would potentially not be made available to the sc/scd instruction due to being in the delay-slot of the branch-likely (beqzl) instruction. This also removes the need for the `noreorder' directive, allowing GAS to use delay slot scheduling as needed. The same fix is also applied to the standard branch (beqz) case in preparation for a follow-up patch that will cleanup/merge the R10000_LLSC_WAR and non-R10K sections together. Signed-off-by:
-
Thomas Bogendoerfer authored
Commit 205e1b7f ("dma-mapping: warn when there is no coherent_dma_mask") introduced a warning, if a device is missing a coherent_dma_mask. ESP and sonic are using dma mapping functions, so they need dma masks. [paul.burton@mips.com: - Wrap commit message.] Signed-off-by:
Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by:
-
- 10 Jul, 2018 2 commits
-
-
Serge Semin authored
Adaptive ioremap_wc() method is now available as of commit 9748e33e ("mips: mm: Create UCA-based ioremap_wc() method"). We can use it to obtain UnCached Accelerated (UCA) mappings safely on all MIPS systems, and so we don't need the MIPS-specific ioremap_uncached_accelerated() any longer. This macro hard-coded the UCA Cache Coherency Attribute (CCA) in a manner that isn't safe for kernels that may run on different CPUs, and it is also entirely unused so we can trivially remove it. [paul.burton@mips.com: - Reword the commit message a little. - Remove CC stable.] Signed-off-by:
-
Serge Semin authored
Modern MIPS cores (like P5600/6600, M5150/6520, end so on) which got L2-cache on chip also can enable a special type Cache-Coherency attribute (CCA) named UnCached Accelerated attribute (UCA). In this way uncached accelerated accesses are treated the same way as non-accelerated uncached accesses, but uncached stores are gathered together for more efficient bus utilization. So to speak this CCA enables uncached transactions to better utilize bus bandwidth via burst transactions. This is exactly why ioremap_wc() method has been introduced in Linux. Alas MIPS-platform code hasn't implemented it so far, instead default one has been used which was an alias to ioremap_nocache. In order to fix this we added MIPS-specific ioremap_wc() macro substituted by generic __ioremap_mode() method call with writecombine CPU-info field passed. It shall create real ioremap_wc() method if CPU-cache supports UCA feature and fall-back to _CACHE_UNCACHED attribute if one doesn't. Additionally platform-specific io.h shall declare ARCH_HAS_IOREMAP_WC macro as indication of architectural definition of ioremap_wc() (similar to x86/powerpc). [paul.burton@mips.com: - Remove CC stable, this is new functionality.] Signed-off-by:
-
- 03 Jul, 2018 6 commits
-
-
Steven J. Hill authored
Collapse and simplify switch statements in functions. Signed-off-by:
Steven J. Hill <steven.hill@cavium.com> Signed-off-by:
-
Steven J. Hill authored
Create new CVMX_CIU_ADDR macro to improve readability. Signed-off-by:
-
Steven J. Hill authored
Get rid of all unused CIU macros and sort them. Verified with 'make allyesconfig' build test. [paul.burton@mips.com: - Also checked via convoluted grep invocation for use of all removed macros within arch/mips/ & drivers/.] Signed-off-by: -
Steven J. Hill authored
Convert remaining structures to use __BITFIELD_FIELD macro. Also straighten up the description text and whitespace. Signed-off-by:
-
Steven J. Hill authored
Data types 'cvmx_ciu_qlm0' and 'cvmx_ciu_qlm1' are identical in their usage and structure. Combine them and update the PCIe code. Signed-off-by:
-
Steven J. Hill authored
Remove all unused data types. Verified with a 'make allyesconfig' and Cavium platform. [paul.burton@mips.com: - Also checked via convoluted grep invocation for use of all removed structs & unions within arch/mips/ & drivers/.] Signed-off-by:
-
- 28 Jun, 2018 4 commits
-
-
Geert Uytterhoeven authored
Coldfire still provides its own variant of the clk API rather than using the generic COMMON_CLK API. This generally works, but it causes some link errors with drivers using the clk_round_rate(), clk_set_rate(), clk_set_parent(), or clk_get_parent() functions when a platform lacks those interfaces. This adds empty stub implementations for each of them, and I don't even try to do something useful here but instead just print a WARN() message to make it obvious what is going on if they ever end up being called. The drivers that call these won't be used on these platforms (otherwise we'd get a link error today), so the added code is harmless bloat and will warn about accidental use. Based on commit bd7fefe1 ("ARM: w90x900: normalize clk API"). Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Paul Burton authored
The VDSO Makefile filters CFLAGS to select a subset which it uses whilst building the VDSO ELF. One of the flags it allows through is the -march= flag that selects the architecture/ISA to target. Unfortunately in cases where CONFIG_CPU_MIPS32_R{1,2}=y and the toolchain defaults to building for MIPS64, the main MIPS Makefile ends up using the short-form -<arch> flags in cflags-y. This is because the calls to cc-option always fail to use the long-form -march=<arch> flag due to the lack of an -mabi=<abi> flag in KBUILD_CFLAGS at the point where the cc-option function is executed. The resulting GCC invocation is something like: $ mips64-linux-gcc -Werror -march=mips32r2 -c -x c /dev/null -o tmp cc1: error: '-march=mips32r2' is not compatible with the selected ABI These short-form -<arch> flags are dropped by the VDSO Makefile's filtering, and so we attempt to build the VDSO without specifying any architecture. This results in an attempt to build the VDSO using whatever the compiler's default architecture is, regardless of whether that is suitable for the kernel configuration. One encountered build failure resulting from this mismatch is a rejection of the sync instruction if the kernel is configured for a MIPS32 or MIPS64 r1 or r2 target but the toolchain defaults to an older architecture revision such as MIPS1 which did not include the sync instruction: CC arch/mips/vdso/gettimeofday.o /tmp/ccGQKoOj.s: Assembler messages: /tmp/ccGQKoOj.s:273: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:329: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:520: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:714: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1009: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1066: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1114: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1279: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1334: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1374: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1459: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1514: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:1814: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:2002: Error: opcode not supported on this processor: mips1 (mips1) `sync' /tmp/ccGQKoOj.s:2066: Error: opcode not supported on this processor: mips1 (mips1) `sync' make[2]: *** [scripts/Makefile.build:318: arch/mips/vdso/gettimeofday.o] Error 1 make[1]: *** [scripts/Makefile.build:558: arch/mips/vdso] Error 2 make[1]: *** Waiting for unfinished jobs.... This can be reproduced for example by attempting to build pistachio_defconfig using Arnd's GCC 8.1.0 mips64 toolchain from kernel.org: https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-mips64-linux.tar.xz Resolve this problem by using the long-form -march=<arch> in all cases, which makes it through the arch/mips/vdso/Makefile's filtering & is thus consistently used to build both the kernel proper & the VDSO. The use of cc-option to prefer the long-form & fall back to the short-form flags makes no sense since the short-form is just an abbreviation for the also-supported long-form in all GCC versions that we support building with. This means there is no case in which we have to use the short-form -<arch> flags, so we can simply remove them. The manual redefinition of _MIPS_ISA is removed naturally along with the use of the short-form flags that it accompanied, and whilst here we remove the separate assembler ISA selection. I suspect that both of these were only required due to the mips32 vs mips2 mismatch that was introduced by commit 59b3e8e9 ("[MIPS] Makefile crapectomy.") and fixed but not cleaned up by commit 9200c0b2 ("[MIPS] Fix Makefile bugs for MIPS32/MIPS64 R1 and R2."). I've marked this for backport as far as v4.4 where the MIPS VDSO was introduced. In earlier kernels there should be no ill effect to using the short-form flags. Signed-off-by:James Hogan <jhogan@kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/19579/
-
Joe Perches authored
random_ether_addr is a #define for eth_random_addr which is generally preferred in kernel code by ~3:1 Convert the uses of random_ether_addr to enable removing the #define Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Paul Burton authored
Annotate cpu_wait implementations using the __cpuidle macro which places these functions in the .cpuidle.text section. This allows cpu_in_idle() to return true for PC values which fall within these functions, allowing nmi_backtrace() to produce cleaner output for CPUs running idle functions. For example: # echo l >/proc/sysrq-trigger [ 38.587170] sysrq: SysRq : Show backtrace of all active CPUs [ 38.593657] NMI backtrace for cpu 1 [ 38.597611] CPU: 1 PID: 161 Comm: sh Not tainted 4.18.0-rc1+ #27 [ 38.604306] Stack : 00000000 00000004 00000006 80486724 00000000 00000000 00000000 00000000 [ 38.613647] 80e17eda 00000034 00000000 00000000 80d20000 80b67e98 8e559c90 0ffe1e88 [ 38.622986] 00000000 00000000 80e70000 00000000 8f61db18 38312e34 722d302e 202b3163 [ 38.632324] 8e559d3c 8e559adc 00000001 6b636162 80d20000 80000000 00000000 80d1cfa4 [ 38.641664] 00000001 80d20000 80d19520 00000000 00000003 80836724 00000004 80e10004 [ 38.650993] ... [ 38.653724] Call Trace: [ 38.656499] [<8040cdd0>] show_stack+0xa0/0x144 [ 38.661475] [<80b67e98>] dump_stack+0xe8/0x120 [ 38.666455] [<80b6f6d4>] nmi_cpu_backtrace+0x1b4/0x1cc [ 38.672189] [<80b6f81c>] nmi_trigger_cpumask_backtrace+0x130/0x1e4 [ 38.679081] [<808295d8>] __handle_sysrq+0xc0/0x180 [ 38.684421] [<80829b84>] write_sysrq_trigger+0x50/0x64 [ 38.690176] [<8061c984>] proc_reg_write+0xd0/0xfc [ 38.695447] [<805aac1c>] __vfs_write+0x54/0x194 [ 38.700500] [<805aaf24>] vfs_write+0xe0/0x18c [ 38.705360] [<805ab190>] ksys_write+0x7c/0xf0 [ 38.710238] [<80416018>] syscall_common+0x34/0x58 [ 38.715558] Sending NMI from CPU 1 to CPUs 0,2-3: [ 38.720916] NMI backtrace for cpu 0 skipped: idling at r4k_wait_irqoff+0x2c/0x34 [ 38.729186] NMI backtrace for cpu 3 skipped: idling at r4k_wait_irqoff+0x2c/0x34 [ 38.737449] NMI backtrace for cpu 2 skipped: idling at r4k_wait_irqoff+0x2c/0x34 Without this we get register value & backtrace output from all CPUs, which is generally useless for those running the idle function & serves only to overwhelm & obfuscate the meaningful output from non-idle CPUs. Signed-off-by:
-
- 24 Jun, 2018 14 commits
-
-
Rickard Strandqvist authored
Remove the function sb1_dma_init() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by:
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Patchwork: https://patchwork.linux-mips.org/patch/8873/Signed-off-by:
-
Rickard Strandqvist authored
Remove the function pci_enable_swapping() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by:
-
Paul Burton authored
Remove the platform code used to power down the system, instead relying upon the new PIIX4 poweroff driver. This reduces the amount of platform code required for the Malta board in preparation for allowing it to be part of a more generic kernel. Signed-off-by:
-
Paul Burton authored
DMA coherence is not user-selectable in Kconfig, and Malta selects CONFIG_DMA_MAYBE_COHERENT which in turn selects CONFIG_DMA_NONCOHERENT. Remove #ifdefs whose conditions can therefore never be true for Malta. This removes a significant amount of code from bonito_quirks_setup(), but the code is duplicated in plat_enable_iocoherency() anyway so we lose nothing but duplication. Signed-off-by:
-
Paul Burton authored
In systems that include a MIPS Coherency Manager, the icache always fills from a cache which is coherent across all CPUs. In I6400 & I6500 systems the icache fills from the dcache which is coherent across all CPUs. In all other CM-based systems the icache fills from the L2 cache which is shared between all cores. This means that an icache will always see stores from remote CPUs without needing to write them back any further than that L2, which is what the cpu_icache_snoops_remote_store feature is used to test. In order for it to return 1 without needing a per-platform override (which is what Malta has relied upon so far) set the MIPS_IC_SNOOPS_REMOTE flag when a CM is present. Signed-off-by:
-
Joshua Kinard authored
This is a manual cherrypick of commit c7ddc3d137b7 from Alastair Bridgewater's IP35 tree that replaces two cases of "if (bus->number > 0)" with a more correct "if (!pci_is_root_bus(bus))" in arch/mips/pci/ops-bridge.c. Cc: linux-mips@linux-mips.org Cc: Alastair Bridgewater <alastair.bridgewater@gmail.com> Suggested-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by:
-
Paul Burton authored
Commit 6b832257 ("MIPS: Force CPUs to lose FP context during mode switches") ensures that we react to PR_SET_FP_MODE prctl syscalls quickly by broadcasting an IPI in order to cause CPUs to lose FPU access when necessary. Whilst it achieves that, unfortunately it causes all sorts of strange race conditions because: 1) The IPI may arrive at a point where the FPU is in the process of being enabled, but that process is not yet complete leading to a state we aren't prepared to handle. For example: [ 370.215903] do_cpu invoked from kernel context![#1]: [ 370.221064] CPU: 0 PID: 963 Comm: fp-prctl Not tainted 4.9.0-rc5-00323-g210db32-dirty #226 [ 370.229420] task: a8000000fd672e00 task.stack: a8000000fd630000 [ 370.235399] $ 0 : 0000000000000000 0000000000000001 0000000000000001 a8000000fd630000 [ 370.243882] $ 4 : a8000000fd672e00 0000000000000000 0000000000000453 0000000000000000 [ 370.252317] $ 8 : 0000000000000000 a8000000fd637c28 1000000000000000 0000000000000010 [ 370.260753] $12 : 00000000140084e0 ffffffff80109c00 0000000000000000 0000000000000002 [ 370.269179] $16 : ffffffff8092f080 a8000000fd672e00 ffffffff80107fe8 a8000000fd485000 [ 370.277612] $20 : ffffffff8084d328 ffffffff80940000 0000000000000009 ffffffff80930000 [ 370.286038] $24 : 0000000000000000 900000001612048c [ 370.294476] $28 : a8000000fd630000 a8000000fd637ac0 ffffffff80937300 ffffffff8010807c [ 370.302909] Hi : 0000000000000000 [ 370.306595] Lo : 0000000000000200 [ 370.310376] epc : ffffffff80115d38 _save_fp+0x10/0xa0 [ 370.315784] ra : ffffffff8010807c prepare_for_fp_mode_switch+0x94/0x1b0 [ 370.322707] Status: 140084e2 KX SX UX KERNEL EXL [ 370.327980] Cause : 1080002c (ExcCode 0b) [ 370.332091] PrId : 0001a428 (MIPS P6600) [ 370.336179] Modules linked in: [ 370.339486] Process fp-prctl (pid: 963, threadinfo=a8000000fd630000, task=a8000000fd672e00, tls=00000000756e67d0) [ 370.349724] Stack : 0000000000000000 a8000000fd557dc0 0000000000000000 ffffffff801ca8e0 [ 370.358161] 0000000000000000 a8000000fd637b9c 0000000000000009 ffffffff80923780 [ 370.366575] ffffffff80850000 ffffffff8011610c 00000000000000b8 ffffffff801a5084 [ 370.374989] ffffffff8084a370 ffffffff8084a388 ffffffff80923780 ffffffff80923828 [ 370.383395] 0000000000010000 ffffffff809237a8 0000000000020000 ffffffff80a40000 [ 370.391817] 000000000000007c 00000000004a0000 00000000756dedd0 ffffffff801a5188 [ 370.400230] a800000002014900 0000000000000001 ffffffff80923780 0000000080923828 [ 370.408644] ffffffff80923780 ffffffff80923780 ffffffff80923828 ffffffff801a521c [ 370.417066] ffffffff80923780 ffffffff80923828 0000000000010000 ffffffff801a8f84 [ 370.425472] ffffffff80a40000 a8000000fd637c20 ffffffff80a39240 0000000000000001 [ 370.433885] ... [ 370.436562] Call Trace: [ 370.439222] [<ffffffff80115d38>] _save_fp+0x10/0xa0 [ 370.444305] [<ffffffff8010807c>] prepare_for_fp_mode_switch+0x94/0x1b0 [ 370.451035] [<ffffffff801ca8e0>] flush_smp_call_function_queue+0xf8/0x230 [ 370.457991] [<ffffffff8011610c>] ipi_call_interrupt+0xc/0x20 [ 370.463814] [<ffffffff801a5084>] __handle_irq_event_percpu+0xc4/0x1a8 [ 370.470404] [<ffffffff801a5188>] handle_irq_event_percpu+0x20/0x68 [ 370.476734] [<ffffffff801a521c>] handle_irq_event+0x4c/0x88 [ 370.482486] [<ffffffff801a8f84>] handle_edge_irq+0x12c/0x210 [ 370.488316] [<ffffffff801a47a0>] generic_handle_irq+0x38/0x48 [ 370.494280] [<ffffffff804a2dbc>] gic_handle_shared_int+0x194/0x268 [ 370.500616] [<ffffffff801a47a0>] generic_handle_irq+0x38/0x48 [ 370.506529] [<ffffffff80107e60>] do_IRQ+0x18/0x28 [ 370.511445] [<ffffffff804a1524>] plat_irq_dispatch+0xc4/0x140 [ 370.517339] [<ffffffff80106230>] ret_from_irq+0x0/0x4 [ 370.522583] [<ffffffff8010fad4>] do_ri+0x4fc/0x7e8 [ 370.527546] [<ffffffff80106220>] ret_from_exception+0x0/0x10 2) The IPI may arrive during kernel use of the FPU, since we generally only disable preemption around use of the FPU & leave interrupts enabled. This can lead to us unexpectedly losing access to the FPU in places where it previously had not been possible. For example: do_cpu invoked from kernel context![#2]: CPU: 2 PID: 7338 Comm: fp-prctl Tainted: G D 4.7.0-00424-g49b0c82 #2 task: 838e4000 ti: 88d38000 task.ti: 88d38000 $ 0 : 00000000 00000001 ffffffff 88d3fef8 $ 4 : 838e4000 88d38004 00000000 00000001 $ 8 : 3400fc01 801f8020 808e9100 24000000 $12 : dbffffff 807b69d8 807b0000 00000000 $16 : 00000000 80786150 00400fc4 809c0398 $20 : 809c0338 0040273c 88d3ff28 808e9d30 $24 : 808e9d30 00400fb4 $28 : 88d38000 88d3fe88 00000000 8011a2ac Hi : 0040273c Lo : 88d3ff28 epc : 80114178 _restore_fp+0x10/0xa0 ra : 8011a2ac mipsr2_decoder+0xd5c/0x1660 Status: 1400fc03 KERNEL EXL IE Cause : 1080002c (ExcCode 0b) PrId : 0001a920 (MIPS I6400) Modules linked in: Process fp-prctl (pid: 7338, threadinfo=88d38000, task=838e4000, tls=766527d0) Stack : 00000000 00000000 00000000 88d3fe98 00000000 00000000 809c0398 809c0338 808e9100 00000000 88d3ff28 00400fc4 00400fc4 0040273c 7fb69e18 004a0000 004a0000 004a0000 7664add0 8010de18 00000000 00000000 88d3fef8 88d3ff28 808e9100 00000000 766527d0 8010e534 000c0000 85755000 8181d580 00000000 00000000 00000000 004a0000 00000000 766527d0 7fb69e18 004a0000 80105c20 ... Call Trace: [<80114178>] _restore_fp+0x10/0xa0 [<8011a2ac>] mipsr2_decoder+0xd5c/0x1660 [<8010de18>] do_ri+0x90/0x6b8 [<80105c20>] ret_from_exception+0x0/0x10 At first glance a simple fix may seem to be to disable interrupts around kernel use of the FPU rather than merely preemption, however this would introduce further overhead outside of the mode switch path & doesn't solve the third problem: 3) The IPI may arrive whilst the kernel is running code that will lead to a preempt_disable() call & FPU usage soon. If this happens then the IPI will be serviced & we'll proceed to enable an FPU whilst the mode switch is in progress, leading to strange & inconsistent behaviour. Further to all of this is a separate but related problem: 4) There are various paths through which we may enable the FPU without the user having triggered a coprocessor 1 disabled exception. These paths are those in which we emulate instructions & then enable the FPU with the expectation that the user might execute an FP instruction shortly afterwards. However these paths have not previously checked whether an FP mode switch is underway for the task, and therefore could enable the FPU whilst such a mode switch is in progress leading to strange & inconsistent behaviour for user code. This patch fixes all of the above by taking a step back & re-examining our approach to FP mode switches. Up until now we have taken these basic steps: a) Prevent any threads that are part of the affected process from being able to obtain ownership of the FPU. b) Cause any threads that are part of the affected process and already have ownership of an FPU to lose it. c) Set the thread flags for each thread that is part of the affected process to reflect the new FP mode. d) Allow threads to obtain ownership of the FPU again. This approach is however more complex than necessary. All that we really require is that the mode switch has occurred for all threads that are part of the affected process before mips_set_process_fp_mode(), and thus the PR_SET_FP_MODE prctl() syscall, returns. This doesn't require that we stop threads from owning or using an FPU whilst a mode switch occurs, only that we force them to relinquish it after the mode switch has occurred such that they next own an FPU with the correct mode configured. Our basic steps therefore simplify to: A) Set the thread flags for each thread that is part of the affected process to reflect the new FP mode. B) Cause any threads that are part of the affected process and already have ownership of an FPU to lose it. We implement B) by forcing each CPU which might be running a thread which is part of the affected process to schedule a no-op function, which causes the affected thread to lose its FPU ownership when it is descheduled. The end result is simpler FP mode switching with less overhead in the FPU enable path (ie. enable_restore_fp_context()) and fewer moving parts. Signed-off-by:
-
Rob Herring authored
The DT core will call of_platform_default_populate, so it is not necessary for arch specific code to call it unless there are custom match entries, auxdata or parent device. Neither of those apply here, so remove the call. Cc: John Crispin <john@phrozen.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@mips.com> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@linux-mips.org Signed-off-by:
Rob Herring <robh@kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/19592/Signed-off-by:
-
Rob Herring authored
The DT core will call of_platform_populate, so it is not necessary for arch specific code to call it unless there are custom match entries, auxdata or parent device. Neither of those apply here, so remove the call. Cc: Paul Burton <paul.burton@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@linux-mips.org Signed-off-by:
-
Rob Herring authored
The DT core will register "simple-bus" by default, so it is not necessary for arch specific code to do so unless there are custom match entries, auxdata or parent device. Neither of those apply here, so remove the call. Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@mips.com> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@linux-mips.org Signed-off-by:
-
Rob Herring authored
The DT core code will probe "simple-bus" by default, so remove the Netlogic specific call. The probing of simple-bus happens at arch_initcall_sync, so the call being removed here is already a nop. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@mips.com> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@linux-mips.org Signed-off-by:
-
Rob Herring authored
of_platform_bus_probe is deprecated in favor of of_platform_populate. of_platform_populate is stricter requiring compatible properties for matching rather than name or type. Octeon uses compatible strings for matching, so convert it to of_platform_populate. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@mips.com> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@linux-mips.org Signed-off-by:
-
Heiher authored
On SMP systems, the shared ejtag debug buffer may be overwritten by other cores, because every cores can generate ejtag exception at same time. Unfortunately, in that context, it's difficult to relax more registers to access per cpu buffers. so use ll/sc to serialize the access. [paul.burton@mips.com: This could in theory be backported at least as far back as the beginning of the git era, however in general it's exceedingly rare that anyone would hit this without further changes, so it doesn't seem worthwhile marking for backport.] Signed-off-by:
Heiher <r@hev.cc> Patchwork: https://patchwork.linux-mips.org/patch/19507/Signed-off-by:
-
Masahiro Yamada authored
Merge the build rule of vmlinux.{gz,bz2,lzma,lzo}.itb, and also move 'targets' close to the related code. [paul.burton@mips.com: - Remove leading tabs from assignments to itb_addr_cells, since after this patch moves the additions to the 'targets' variable the assignments to itb_addr_cells wound up being treated as part of the uImage rule above them, causing the .its to incorrectly be generated with empty ADDR_CELLS.] Signed-off-by:Masahiro Yamada <yamada.masahiro@socionext.com> Patchwork: https://patchwork.linux-mips.org/patch/19095/Signed-off-by:
-
