- 20 Apr, 2023 25 commits
-
-
Nicholas Piggin authored
Add an option to build kernel and module with prefixed instructions if the CPU and toolchain support it. This is not related to kernel support for userspace execution of prefixed instructions. Building with prefixed instructions breaks some extended inline asm memory addressing, for example it will provide immediates that exceed the range of simple load/store displacement. Whether this is a toolchain or a kernel asm problem remains to be seen. For now, these are replaced with simpler and less efficient direct register addressing when compiling with prefixed. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-4-npiggin@gmail.com
-
Nicholas Piggin authored
This mostly consolidates the Book3E and Book3S behaviour in boot WRT executing from the physical or virtual address. Book3E sets up kernel virtual linear map in start_initialization_book3e and runs from the virtual linear alias after that. This change makes Book3S begin to execute from the virtual alias at the same point. Book3S can not use its MMU for that at this point, but when the MMU is disabled, the virtual linear address correctly aliases to physical memory because the top bits of the address are ignored with MMU disabled. Secondaries execute from the virtual address similarly early. This reduces the differences between subarchs, but the main motivation was to enable the PC-relative addressing ABI for Book3S, where pointer calculations must execute from the virtual address or the top bits of the pointer will be lost. This is similar to the requirement the TOC relative addressing already has that the TOC pointer use its virtual address. Signed-off-by:
-
Nicholas Piggin authored
A later change moves the non-prom case to run at the virtual address earlier, which calls for virtual TOC and kernel base. Split these two calculations for prom and non-prom to make that change simpler. Signed-off-by:
-
Pali Rohár authored
"fsl,P2020RDB-PC" compatible string was present in Turris 1.x DTS file just because Linux kernel required it for proper detection of P2020 processor during boot. This was quite a hack as CZ.NIC Turris 1.x is not compatible with Freescale P2020-RDB-PC board. Now when kernel has generic unified support for boards with P2020 processors, there is no need to have this "hack" in turris1x.dts file. So remove incorrect "fsl,P2020RDB-PC" compatible string from turris1x.dts. Signed-off-by:
Pali Rohár <pali@kernel.org> Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
-
Pali Rohár authored
Generic unified P2020 machine description which supports all P2020-based boards is now in separate file p2020.c. So create a separate config option CONFIG_PPC_P2020 for it. Previously machine descriptions for P2020 boards were enabled by CONFIG_MPC85xx_DS or CONFIG_MPC85xx_RDB option. So set CONFIG_PPC_P2020 to be enabled by default when one of those option is enabled. This allows to compile support for P2020 boards without need to have enabled support for older mpc85xx boards. And to compile kernel for old mpc85xx boards without having enabled support for new P2020 boards. Signed-off-by:
-
Pali Rohár authored
Combine machine descriptions and code of all P2020 boards into just one generic unified P2020 machine description. This allows kernel to boot on any P2020-based board with P2020 DTS file without need to patch kernel and define a new machine description in 85xx powerpc platform directory. Signed-off-by:
-
Pali Rohár authored
Make just one .setup_arch and one .init_IRQ callback implementation for all P2020 board code. This deduplicate repeated and same code. Signed-off-by:
-
Pali Rohár authored
In order to share mpc85xx i8259 code between DS and P2020. Prefix i8259 debug and error messages by i8259 word. Signed-off-by:
-
Pali Rohár authored
This moves P2020 RDB machine descriptions into new p2020.c source file. This is preparation for code de-duplication and providing one unified machine description for all P2020 boards. Signed-off-by:
-
Pali Rohár authored
This moves P2020 DS machine descriptions into new p2020.c source file. This is preparation for code de-duplication and providing one unified machine description for all P2020 boards. Signed-off-by:
-
Christophe Leroy authored
mpc85xx_qe_par_io_init() is a stub when CONFIG_QUICC_ENGINE is not set. CONFIG_UCC_GETH and CONFIG_SERIAL_QE depend on CONFIG_QUICC_ENGINE. Remove #ifdef CONFIG_QUICC_ENGINE Signed-off-by:
-
Christophe Leroy authored
All necessary items are declared all the time, no need to use a #ifdef CONFIG_PPC_I8259. Refactor CONFIG_PPC_I8259 actions into a dedicated init function. Signed-off-by:
-
Christophe Leroy authored
Use pr_debug() instead of printk(KERN_DEBUG Use pr_err() instead of printk(KERN_ERR Use pr_info() instead of printk(KERN_INFO or printk(" Signed-off-by: -
Christophe Leroy authored
No need to BUG() in case mpic_alloc() fails. Use WARN_ON(). Signed-off-by:
-
Christophe Leroy authored
Reduce number of lines in the call to mpic_alloc(). Signed-off-by:
-
Christophe Leroy authored
DBG() macro is defined at three places while used only one time at one place. Replace its only use by a pr_debug() and remove the macro. Signed-off-by:
-
Pali Rohár authored
Function uli_exclude_device() is not used outside of the fsl_uli1575.c source file anymore. So mark it as static and remove public prototype. Signed-off-by:
-
Pali Rohár authored
After calling fsl_pci_assign_primary(), it is possible to use uli_init() to conditionally initialize ppc_md.pci_exclude_device callback based on the uli1575 detection. Signed-off-by:
-
Pali Rohár authored
ULI1575 PCIe south bridge exists only on some Freescale boards. Allow to disable CONFIG_FSL_ULI1575 symbol when it is not explicitly selected and only implied. This is achieved by marking symbol as visible by providing short description. Also adds dependency for this symbol to prevent enabling it on platforms on which driver does not compile. Signed-off-by:
-
Pali Rohár authored
Boards provided by CONFIG_MPC85xx_RDB option do not initialize fsl_uli1575.c driver. So remove explicit select dependency on it. Signed-off-by:
-
Pali Rohár authored
Move uli_init() function into existing driver fsl_uli1575.c file in order to share its code between more platforms and board files. Signed-off-by:
-
Pali Rohár authored
Function uli_exclude_device() is called only from mpc86xx_exclude_device() and mpc85xx_exclude_device() functions. Both those functions are same, so merge its logic directly into the uli_exclude_device() function. Signed-off-by:
-
Pali Rohár authored
Function mpc85xx_exclude_device() is installed and used only when pci_with_uli is fsl_pci_primary. So replace check for pci_with_uli by fsl_pci_primary in mpc85xx_exclude_device() and move pci_with_uli variable declaration into function mpc85xx_ds_uli_init() where it is used. Signed-off-by:
-
Christophe Leroy authored
Use a single line for uli_exclude_device(). Add uli_exclude_device() prototype in ppc-pci.h and guard it. Remove that prototype from mpc85xx_ds.c and mpc86xx_hpcn.c files. Make uli_pirq_to_irq[] static as it is used only in that file. Signed-off-by:
-
Nicholas Piggin authored
-mcpu=power10 will generate prefixed and pcrel code by default, which we do not support. The general kernel disables these with cflags, but those were missed for the boot wrapper. Fixes: 4b2a9315 ("powerpc/64s: POWER10 CPU Kconfig build option") Cc: stable@vger.kernel.org # v6.1+ Reported-by:
Danny Tsen <dtsen@linux.ibm.com> Signed-off-by:
-
- 12 Apr, 2023 1 commit
-
-
Nicholas Piggin authored
Use the preferred form of branch-and-link for finding the current address so objtool doesn't think it is an unannotated intra-function call. Signed-off-by:
-
- 11 Apr, 2023 10 commits
-
-
Nathan Chancellor authored
When building with W=1 after commit 80b6093b ("kbuild: add -Wundef to KBUILD_CPPFLAGS for W=1 builds"), the following warning occurs. In file included from arch/powerpc/kvm/bookehv_interrupts.S:26: arch/powerpc/kvm/../kernel/head_booke.h:20:6: warning: "THREAD_SHIFT" is not defined, evaluates to 0 [-Wundef] 20 | #if (THREAD_SHIFT < 15) | ^~~~~~~~~~~~ THREAD_SHIFT is defined in thread_info.h but it is not directly included in head_booke.h, so it is possible for THREAD_SHIFT to be undefined. Add the include to ensure that THREAD_SHIFT is always defined. Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/202304050954.yskLdczH-lkp@intel.com/Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Nicholas Piggin authored
syscalls do not set the PPR field in their interrupt frame and return from syscall always sets the default PPR for userspace, so setting the value in the ret_from_fork frame is not necessary and mildly inconsistent. Remove it. Signed-off-by:
-
Nicholas Piggin authored
In the kernel user thread path, don't set _TIF_RESTOREALL because the thread is required to call kernel_execve() before it returns, which will set _TIF_RESTOREALL if necessary via start_thread(). Signed-off-by:
-
Nicholas Piggin authored
Kernel created user threads start similarly to kernel threads in that they call a kernel function after first returning from _switch, so they share ret_from_kernel_thread for this. Kernel threads never return from that function though, whereas user threads often do (although some don't, e.g., IO threads). Split these startup functions in two, and catch kernel threads that improperly return from their function. This is intended to make the complicated code a little bit easier to understand. Signed-off-by:
-
Nicholas Piggin authored
When copy_thread is given a kernel function to run in arg->fn, this does not necessarily mean it is a kernel thread. User threads can be created this way (e.g., kernel_init, see also x86's copy_thread()). These threads run a kernel function which may call kernel_execve() and return, which returns like a userspace exec(2) syscall. Kernel threads are to be differentiated with PF_KTHREAD, will always have arg->fn set, and should never return from that function, instead calling kthread_exit() to exit. Create separate paths for the kthread and user kernel thread creation logic. The kthread path will never exit and does not require a user interrupt frame, so it gets a minimal stack frame. Signed-off-by:
-
Nicholas Piggin authored
If the system call return path always restores NVGPRs then there is no need for ret_from_fork to do it. The HANDLER_RESTORE_NVGPRS does the right thing for this. Signed-off-by:
-
Nicholas Piggin authored
The kernel thread path in copy_thread creates a user interrupt frame on stack and stores the function and arg parameters there, and ret_from_kernel_thread loads them. This is a slightly confusing way to overload that frame. Non-volatile registers are loaded from the switch frame, so the parameters can be stored there. The user interrupt frame is now only used by user threads when they return to user. Signed-off-by:
-
Nicholas Piggin authored
The ret_from_fork code for 64e and 32-bit set r3 for syscall_exit_prepare the same way that 64s does, so there should be no need to special-case them in copy_thread. Signed-off-by:
-
Nicholas Piggin authored
The pkey registers (AMR, IAMR) do not get loaded from the switch frame so it is pointless to save anything there. Remove the dead code. Signed-off-by:
-
Michael Ellerman authored
The amdgpu driver builds some of its code with hard-float enabled, whereas the rest of the kernel is built with soft-float. When building with 64-bit long double, if soft-float and hard-float objects are linked together, the build fails due to incompatible ABI tags. In the past there have been build errors in the amdgpu driver caused by this, some of those were due to bad intermingling of soft & hard-float code, but those issues have now all been fixed since commit 58ddbecb ("drm/amd/display: move remaining FPU code to dml folder"). However it's still possible for soft & hard-float objects to end up linked together, if the amdgpu driver is built-in to the kernel along with the test_emulate_step.c code, which uses soft-float. That happens in an allyesconfig build. Currently those build errors are avoided because the amdgpu driver is gated on 128-bit long double being enabled. But that's not a detail the amdgpu driver should need to be aware of, and if another driver starts using hard-float the same problem would occur. All versions of the 64-bit ABI specify that long-double is 128-bits. However some compilers, notably the kernel.org ones, are built to use 64-bit long double by default. Apart from this issue of soft vs hard-float, the kernel doesn't care what size long double is. In particular the kernel using 128-bit long double doesn't impact userspace's ability to use 64-bit long double, as musl does. So always build the 64-bit kernel with 128-bit long double. That should avoid any build errors due to the incompatible ABI tags. Excluding the code that uses soft/hard-float, the vmlinux is identical with/without the flag. It does mean any code which is incorrectly intermingling soft & hard-float code will build without error, so those bugs will need to be caught by testing rather than at build time. For more background see: - commit d11219ad ("amdgpu: disable powerpc support for the newer display engine") - commit c653c591 ("drm/amdgpu: Re-enable DCN for 64-bit powerpc") - https://lore.kernel.org/r/dab9cbd8-2626-4b99-8098-31fe76397d2d@app.fastmail.comSigned-off-by:
Segher Boessenkool <segher@kernel.crashing.org> Link: https://msgid.link/20230404102847.3303623-1-mpe@ellerman.id.au
-
- 04 Apr, 2023 4 commits
-
-
Nysal Jan K.A authored
Remove arch_atomic_try_cmpxchg_lock function as it is no longer used since commit 9f61521c ("powerpc/qspinlock: powerpc qspinlock implementation") Signed-off-by:
Nysal Jan K.A <nysal@linux.ibm.com> Reviewed-by:
-
Nicholas Miehlbradt authored
Walks the stack when copy_{to,from}_user address is in the stack to ensure that the object being copied is entirely a single stack frame and does not contain stack metadata. Substantially similar to the x86 implementation. The back chain is used to traverse the stack and identify stack frame boundaries. Signed-off-by:Nicholas Miehlbradt <nicholas@linux.ibm.com> Signed-off-by:
-
Rob Herring authored
Replace open coded reading of "reg" or of_get_address()/ of_translate_address() calls with a single call to of_address_to_resource(). Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Rob Herring authored
Replace of_get_property()+of_translate_address()+ioremap() with a call to of_iomap() which does all those steps. Signed-off-by:
-
