- 20 Nov, 2018 1 commit
-
-
Hassan Naveed authored
Select ARCH_HAS_UBSAN_SANITIZE_ALL in order to allow the user to enable CONFIG_UBSAN_SANITIZE_ALL and instrument the entire kernel for ubsan checks. We exclude the VDSO from this because its build doesn't include the __ubsan_handle_*() functions that the kernel proper defines in from lib/ubsan.c, and the VDSO would have no sane way to report errors even if it had definitions of these functions. Signed-off-by:
Hassan Naveed <hnaveed@wavecomp.com> Reviewed-by:
Paul Burton <paul.burton@mips.com> Signed-off-by:
-
- 19 Nov, 2018 3 commits
-
-
Huacai Chen authored
Loongson-3A R2.1 is the bugfix revision of Loongson-3A R2. All Loongson-3 CPU family: Code-name Brand-name PRId Loongson-3A R1 Loongson-3A1000 0x6305 Loongson-3A R2 Loongson-3A2000 0x6308 Loongson-3A R2.1 Loongson-3A2000 0x630c 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:
-
Sean Young authored
When building BPF code using "clang -target bpf -c", clang does not define __linux__. To build BPF IR decoders the include linux/lirc.h is needed which includes linux/types.h. Currently this workaround is needed: https://git.linuxtv.org/v4l-utils.git/commit/?id=dd3ff81f58c4e1e6f33765dc61ad33c48ae6bb07 This check might otherwise be useful to stop users from using a non-linux compiler, but if you're doing that you are going to have a lot more trouble anyway. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Rob Herring authored
Remove directly accessing device_node.type pointer and use the accessors instead. This will eventually allow removing the type pointer. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 15 Nov, 2018 3 commits
-
-
Maciej W. Rozycki authored
The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip DRAM controller that supports memory amounts of up to 16GiB, and due to how the address decoder has been wired in the SOC any memory beyond 1GiB is actually mapped starting from 4GiB physical up, that is beyond the 32-bit addressable limit[1]. Consequently if the maximum amount of memory has been installed, then it will span up to 19GiB. Many of the evaluation boards we support that are based on one of these SOCs have their memory soldered and the amount present fits in the 32-bit address range. The BCM91250A SWARM board however has actual DIMM slots and accepts, depending on the peripherals revision of the SOC, up to 4GiB or 8GiB of memory in commercially available JEDEC modules[2]. I believe this is also the case with the BCM91250C2 LittleSur board. This means that up to either 3GiB or 7GiB of memory requires 64-bit addressing to access. I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead, accepts at least as much memory, although I have no documentation or actual hardware available to verify that. Both systems have PCI slots installed for use by any PCI option boards, including ones that only support 32-bit addressing (additionally the 32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits addressing to 32-bits), and there is no IOMMU available. Therefore for PCI DMA to work in the presence of memory beyond enable swiotlb for the affected systems. All the other SOC onchip DMA devices use 40-bit addressing and therefore can address the whole memory, so only enable swiotlb if PCI support and support for DMA beyond 4GiB have been both enabled in the configuration of the kernel. This shows up as follows: Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2) Board type: SiByte BCM91250A (SWARM) Determined physical RAM map: memory: 000000000fe7fe00 @ 0000000000000000 (usable) memory: 000000001ffffe00 @ 0000000080000000 (usable) memory: 000000000ffffe00 @ 00000000c0000000 (usable) memory: 0000000087fffe00 @ 0000000100000000 (usable) software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB) in the bootstrap log and removes failures like these: defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0 fddi0: Receive buffer allocation failed fddi0: Adapter open failed! IP-Config: Failed to open fddi0 defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0 fddi1: Receive buffer allocation failed fddi1: Adapter open failed! IP-Config: Failed to open fddi1 when memory beyond 4GiB is handed out to devices that can only do 32-bit addressing. This updates commit cce335ae ("[MIPS] 64-bit Sibyte kernels need DMA32."). References: [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview", "Memory Map", pp. 34-38 [2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom Corporation, 18 May 2004, Section 3: "Physical Description", "Supported DRAM", p. 23 Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> [paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it] Signed-off-by:
Christoph Hellwig <hch@lst.de> Patchwork: https://patchwork.linux-mips.org/patch/21108/ References: cce335ae ("[MIPS] 64-bit Sibyte kernels need DMA32.") Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org
-
Maciej W. Rozycki authored
The LittleSur board is marked for high memory support and therefore clearly must provide a way to have enough memory installed for some to be present outside the low 4GiB physical address range. With the memory map of the BCM1250 SOC it has been built around it means over 1GiB of actual DRAM, as only the first 1GiB is mapped in the low 4GiB physical address range[1]. Complement commit cce335ae ("[MIPS] 64-bit Sibyte kernels need DMA32.") then and also enable ZONE_DMA32 for LittleSur. References: [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview", "Memory Map", pp. 34-38 Signed-off-by:
-
Maciej W. Rozycki authored
The Broadcom SiByte BCM1250, BCM1125H and BCM1125 SOCs have an onchip 32-bit PCI host bridge, and the two former SOCs also have an onchip HT host bridge. The HT host bridge, where present, appears in the PCI configuration space as if it was a device on the 32-bit PCI bus behind the PCI host bridge, however at the hardware level its signals are routed separately, so these two devices are actually peer host bridges. As documented[1] and observed in reality the 32-bit PCI host bridge does not support 64-bit addressing as it does not support the Dual Address Cycle (DAC) PCI command, and naturally, being 32-bit only, it has no means to carry the high 32 address bits otherwise. However the DRAM controller also included in the SOC supports memory amounts of up to 16GiB, and due to how the address decoder has been wired in the SOC any memory beyond 1GiB is actually mapped starting from 4GiB physical up, that is beyond the 32-bit addressable limit. Consequently if the maximum amount of memory has been installed, then it will span up to 19GiB. Contrariwise, the HT host bridge does support full 40-bit addressing defined by the HyperTransport (formerly LDT) specification the bridge adheres to, depending on the peripherals revision of the SOC[2] either revision 0.17[3] or revision 1.03[4]. This allows addressing any and all memory installed, and well beyond. Set the bus mask then to limit DMA addressing to 32 bits for all the devices down the 32-bit PCI host bridge, excluding however any devices that are down the HT host bridge. References: [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, Broadcom Corporation, 21 Oct 2002, Section 8: "PCI Bus and HyperTransport Fabric", "Introduction", p. 190 [2] same, Table 140: "HyperTransport Configuration Header (Type 1)", p. 245 [3] "Lightning Data Transport IO Specification", Revision 0.17, Advanced Micro Devices, 21 Jan 2000, Section 3.2.1.2 "Command Packet", p. 8 [4] "HyperTransport I/O Link Specification", Revision 1.03, HyperTransport Technology Consortium, 10 Oct 2001, Section 3.2.1.2 "Request Packet", pp. 27-28 Signed-off-by:
-
- 12 Nov, 2018 4 commits
-
-
Paul Burton authored
The CPU_NO_EFFICIENT_FFS pre-processor macro is no longer used, with all architectures toggling the equivalent Kconfig symbol CONFIG_CPU_NO_EFFICIENT_FFS instead. Remove our check for the unused macro. Signed-off-by:
-
Paul Burton authored
Select CONFIG_CPU_NO_EFFICIENT_FFS via Kconfig when the kernel is configured for a pre-MIPS32r1 CPU, rather than defining its equivalent in asm/cpu-features.h based upon overrides of cpu_has_mips* macros. The latter only works if a platform has an cpu-feature-overrides.h header which defines cpu_has_mips* macros, which are not generally needed. There are many cases where we know that the target ISA for a kernel build is MIPS32r1 or later & thus includes the CLZ instruction, without requiring any overrides from the platform. Using Kconfig allows us to take those into account, and more naturally make a decision about instruction support using information about the target ISA. Signed-off-by:
-
Maksym Kokhan authored
Sort configs in menu "Machine selection" under MIPS_MALTA. Signed-off-by:
Maksym Kokhan <maksym.kokhan@globallogic.com> Signed-off-by:
Andrii Bordunov <andrew.bordunov@gmail.com> Signed-off-by:
-
Maksym Kokhan authored
CONFIG_BUILTIN_DTB and CONFIG_LIBFDT selection is duplicated in menu "Machine selection" under MIPS_MALTA. Signed-off-by:
-
- 10 Nov, 2018 3 commits
-
-
Paul Burton authored
The Intel EG20T Platform Controller Hub used on the MIPS Boston development board supports prefetching memory to optimize DMA transfers. Unfortunately for unknown reasons this doesn't work well with some MIPS CPUs such as the P6600, particularly when using an I/O Coherence Unit (IOCU) to provide cache-coherent DMA. In these systems it is common for DMA data to be lost, resulting in broken access to EG20T devices such as the MMC or SATA controllers. Support for a DT property to configure the prefetching was added a while back by commit 549ce8f1 ("misc: pch_phub: Read prefetch value from device tree if passed") but we never added the DT snippet to make use of it. Add that now in order to disable the prefetching & fix DMA on the affected systems. Signed-off-by:
-
Paul Burton authored
MIPSr6 removed the Hi & Lo registers, so displaying their values on MIPSr6 systems is pointless. Avoid doing so. Signed-off-by:
-
Paul Burton authored
A closing brace in do_ade() has misleading indentation; fix it. Signed-off-by:
-
- 09 Nov, 2018 19 commits
-
-
Paul Burton authored
We currently have 2 commonly used methods for switching ISA within assembly code, then restoring the original ISA. 1) Using a pair of .set push & .set pop directives. For example: .set push .set mips32r2 <some_insn> .set pop 2) Using .set mips0 to restore the ISA originally specified on the command line. For example: .set mips32r2 <some_insn> .set mips0 Unfortunately method 2 does not work with nanoMIPS toolchains, where the assembler rejects the .set mips0 directive like so: Error: cannot change ISA from nanoMIPS to mips0 In preparation for supporting nanoMIPS builds, switch all instances of method 2 in generic non-platform-specific code to use push & pop as in method 1 instead. The .set push & .set pop is arguably cleaner anyway, and if nothing else it's good to consistently use one method. Signed-off-by: -
Paul Burton authored
Allow the user to configure the kernel to omit support for floating point, by setting CONFIG_MIPS_FP_SUPPORT=n. In an attempt to avoid problems for users who don't understand the impact of this, only expose the option when CONFIG_EXPERT=y. When CONFIG_MIPS_FP_SUPPORT=n all support for FPU hardware, FPU emulation & FP context will be removed from the kernel. If a userland program attempts to execute a floating point instruction it will receive a SIGILL. Setting CONFIG_MIPS_FP_SUPPORT=n shaves around 112KB from a 64r6el_defconfig build using GCC 8.1.0. This also helps prepare us for supporting the nanoMIPS ISA, for which floating point support has not been finalized. Signed-off-by:
-
Paul Burton authored
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point & so don't need to preserve floating point context for tasks. Remove that context from struct task_struct. Signed-off-by:
-
Paul Burton authored
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so there's no point compiling in our FPU emulator. Avoid doing so, providing stub versions of dsemul cleanup functions that are called from signal & task handling code. Signed-off-by:
-
Paul Burton authored
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so we don't need to worry about floating point exceptions pending in the Floating point Control & Status Register (FCSR) during switch_to(). Stub out the __sanitize_fcr31() macro in this case. Signed-off-by:
-
Paul Burton authored
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so we can avoid needless checks of ELF headers specifying the FP ABI or NaN encoding to use. Deselect CONFIG_ARCH_BINFMT_ELF_STATE in this case to avoid the need for our arch_elf_pt_proc() & arch_check_elf() functions, and stub out the mips_set_personality_nan() & mips_set_personality_fp() functions such that SET_PERSONALITY() doesn't need to worry about any of this. Signed-off-by:
-
Paul Burton authored
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so there's no need to save & restore floating point context around signals. This prepares us for the removal of FP context from struct task_struct later. Since MSA context is a superset of FP context support for it similarly needs to be removed when MSA/FP support is disabled. Signed-off-by:
-
Paul Burton authored
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so remove the related ptrace support. Besides removing code which should not be needed, this prepares us for the removal of FPU state in struct task_struct which this code requires. Signed-off-by:
-
Paul Burton authored
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so remove support for floating point instructions from emulate_load_store_insn() & emulate_load_store_microMIPS(). This code should not be needed & relies upon access to FPU state in struct task_struct which will later be removed. Similarly & for the same reasons, when CONFIG_CPU_HAS_MSA=n remove support for MSA instructions. Since MSA support depends upon FP support this is implied when CONFIG_MIPS_FP_SUPPORT=n. Signed-off-by:
-
Paul Burton authored
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so remove the floating point branch support from __compute_return_epc_for_insn() & __mm_isBranchInstr(). This code should never be needed & more importantly relies upon FPU state in struct task_struct which will later be removed. Signed-off-by:
-
Paul Burton authored
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so we'll never need to enable the FPU. Avoid doing so on a Co-Processor Unusable exception (do_cpu), and remove the Floating Point Exception handler (do_fpe) which should never be executed when the FPU is disabled. Signed-off-by:
-
Paul Burton authored
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point so there's no point in attempting to detect an FPU. Avoid doing so. Signed-off-by:
-
Paul Burton authored
Provide stub versions of functions in asm/fpu.h when CONFIG_MIPS_FP_SUPPORT=n. Two approaches are taken to the functions provided: - Functions which can safely be called when FP is not enabled provide stubs which return an error where appropriate or are simple no-ops. - Functions which should only ever be called in cases where cpu_has_fpu is true or the FPU was successfully enabled are declared extern & annotated with __compiletime_error() to detect cases in which they are called incorrectly. Signed-off-by: -
Paul Burton authored
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so there's no point in detecting presence of an FPU. Hardcode cpu_has_fpu=0 such that we optimize out code that makes use of the FPU. Signed-off-by:
-
Paul Burton authored
Introduce a Kconfig variable that will indicate whether to include support for floating point in the kernel. For now this is always enabled, and will be made configurable in a later patch. Signed-off-by:
-
Paul Burton authored
Introduce a CONFIG_CPU_R2300_FPU Kconfig symbol mirroring the existing CONFIG_CPU_R4K_FPU, and use it to determine whether to build r4k_fpu.S. This removes the duplicate R3000 & TX39XX cases in arch/mips/kernel/Makefile and prepares us for the possibility of disabling FP support later. Signed-off-by:
-
Paul Burton authored
asm/fpu.h contains forward declarations of struct sigcontext & struct sigcontext32 which appear to have been unused since commit 137f6f3e ("MIPS: Cleanup signal code initialization"). Remove the dead code. Signed-off-by:
-
Paul Burton authored
Emulated floating point instructions don't ensure that the PF_USED_MATH flag is set for the task. This results in a couple of inconsistencies: - ptrace will return the default initial state of FP registers rather than the values actually stored in struct thread_struct, hiding state that has been updated by emulated floating point instructions. - If a task migrates to a CPU with an FPU after having emulated floating point instructions then its floating point register state will be reset to the default ~0 bit pattern, losing state from the emulated instructions. Fix this by calling init_fp_ctx() from fpu_emulator_cop1Handler() to consistently initialize FP state if it was previously uninitialized, setting the PF_USED_MATH flag in the process. All callers of fpu_emulator_cop1Handler() either call lose_fpu(1) before it in order to save any live FPU registers to struct thread_struct, or in the case of do_cpu() already know that the task does not own an FPU so lose_fpu(1) would be a no-op. Since we know that saving FP context will be unnecessary in the case where FP context was just initialized we move this call into fpu_emulator_cop1Handler() too, providing consistency & avoiding needless duplication. Calls to own_fpu(1) are common after return from fpu_emulator_cop1Handler() too, but this would not be a no-op in the do_cpu() case so these are left as-is. A potential future improvement could be to have fpu_emulator_cop1Handler() restore FPU state automatically only if it saved it, though this may not be optimal if some callers are better off without their current calls to own_fpu(1). One potential example of this could be mipsr2_decoder() which as-is could end up saving & restoring FP context repeatedly & unnecessarily if emulating multiple FP instructions. Signed-off-by: -
Paul Burton authored
MIPS has up until now had 3 different ways for a task's floating point context to be initialized: - If the task's first use of FP involves it gaining ownership of an FPU then _init_fpu() is used to initialize the FPU's registers such that they all contain ~0, and the FPU registers will be stored to struct thread_info later (eg. when context switching). - If the task first uses FP on a CPU without an associated FPU then fpu_emulator_init_fpu() initializes the task's floating point register state in struct thread_info such that all floating point register contain the bit pattern 0x7ff800007ff80000, different to the _init_fpu() behaviour. - If a task's floating point context is first accessed via ptrace then init_fp_ctx() initializes the floating point register state in struct thread_info to ~0, giving equivalent state to _init_fpu(). The _init_fpu() path has 2 separate implementations - one for r2k/r3k style systems & one for r4k style systems. The _init_fpu() path also requires that we be careful to clear & restore the value of the Config5.FRE bit on modern systems in order to avoid inadvertently triggering floating point exceptions. None of this code is in a performance critical hot path - it runs only the first time a task uses floating point. As such it doesn't seem to warrant the complications of maintaining the _init_fpu() path. Remove _init_fpu() & fpu_emulator_init_fpu(), instead using init_fp_ctx() consistently to initialize floating point register state in struct thread_info. Upon a task's first use of floating point this will typically mean that we initialize state in memory & then load it into FPU registers using _restore_fp() just as we would on a context switch. For other paths such as __compute_return_epc_for_insn() or mipsr2_decoder() this results in a significant simplification of the work to be done. Signed-off-by:
-
- 08 Nov, 2018 5 commits
-
-
Paul Burton authored
The BMIPS5xxx core_init function contains a call to an init_fpu function inside an #ifdef whose condition never evaluates true. Remove the dead code. FPU initialization happens later, primarily when a userland program attempts to use it. Signed-off-by:
-
Paul Burton authored
From MIPSr6 onwards FP64 support is mandatory, and so CONFIG_MIPS_O32_FP64_SUPPORT is always selected for configurations which support O32 binaries. Hide the useless unchangeable prompt in these cases. Signed-off-by:
-
Paul Burton authored
If we built the kernel targeting the microMIPS ISA then the very fact that the kernel is running implies that the CPU supports microMIPS. Thus we can hardcode cpu_has_mmips to 1 allowing the compiler greater scope for optimisation due to the compile-time constant. Signed-off-by:
-
Paul Burton authored
The GCC_OFF_SMALL_ASM macro defines the constraint to use for instructions needing "small offsets", typically the LL or SC instructions. Historically these had 16 bit offsets, but microMIPS & MIPS32/MIPS64r6 onwards reduced the width of the offset field. GCC 4.9 & higher supports a ZC constraint which matches the offset requirements of the LL & SC instructions. Where supported we can use the ZC constraint regardless of ISA, and it will handle the requirements of the ISA correctly. As such we require 3 cases: - GCC 4.9 & higher can use ZC. - GCC older than 4.9 must use the older R constraint, which does not take into account microMIPS or MIPSr6. - microMIPS builds therefore require GCC 4.9 or higher. MIPSr6 support was only introduced in newer compilers anyway so it can be ignored here. The current code complicates this a little by specifically having MIPSr6 bypass the GCC version check, and using the R constraint for pre-MIPSr6 builds even if the compiler supports ZC which would be equivalent. Simplify this such that the code straightforwardly implements the 3 cases outlined above. For non-GCC compilers we presume that ZC is safe to use. In practice the only non-GCC compiler of interest is clang and it has supported the ZC constraint since version 3.7.0. It seems safe enough to presume that nobody will expect to built a working kernel using a clang version older than that, and if they do then they'll have bigger problems. As such we don't check the clang version number & just presume ZC is usable when the compiler is not GCC. Signed-off-by: -
Paul Burton authored
asm/compiler.h defined GCC_IMM_ASM & GCC_REG_ACCUM macros, both of which are defined differently for GCC pre-3.4 or GCC 3.4 & higher. We only support building with GCC 4.6 & higher since commit cafa0010 ("Raise the minimum required gcc version to 4.6"), which makes the pre-3.4 definition dead code. Rather than leave the macro definitions around, inline the GCC 3.4 & higher definitions into the single file that uses them & remove the macros entirely. Signed-off-by:
-
- 06 Nov, 2018 2 commits
-
-
Maciej W. Rozycki authored
This supports computers based on the R4000SC processor: * DECstation 5000/150 and DECsystem 5000/150, * Personal DECstation 5000/50, Personal DECsystem 5000/50, and computers based on the R4400SC processor: * DECstation 5000/260 and DECsystem 5000/260, * DECsystem 5900/260, in the 64-bit mode. Signed-off-by:
-
Maciej W. Rozycki authored
This supports computers based on the R4000SC processor: * DECstation 5000/150 and DECsystem 5000/150, * Personal DECstation 5000/50, Personal DECsystem 5000/50, and computers based on the R4400SC processor: * DECstation 5000/260 and DECsystem 5000/260, * DECsystem 5900/260, in the 32-bit mode. Signed-off-by:
-
