- 20 Apr, 2023 30 commits
-
-
Benjamin Gray authored
Correct a couple of typos while working on other improvements to the DSCR tests. Signed-off-by: Benjamin Gray <bgray@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230406043320.125138-2-bgray@linux.ibm.com
-
Joel Stanley authored
There are two copies of these defines. Keep the older ones as they have associated bit definitions. Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230405045316.95003-1-joel@jms.id.au
-
Nicholas Piggin authored
Build modules using PCREL addressing when CONFIG_PPC_KERNEL_PCREL=y. - The module loader must handle several new relocation types: * R_PPC64_REL24_NOTOC is a function call handled like R_PPC_REL24, but does not restore r2 upon return. The external function call stub is changed to use pcrel addressing to load the function pointer rather than based on the module TOC. * R_PPC64_GOT_PCREL34 is a reference to external data. A GOT table must be built by hand, because the linker adds this during the final link (which is not done for kernel modules). The GOT table is built similarly to the way the external function call stub table is. This section is called .mygot because .got has a special meaning for the linker and can become upset. * R_PPC64_PCREL34 is used for local data addressing, but there is a special case where the percpu section is moved at load-time to the percpu area which is out of range of this relocation. This requires the PCREL34 relocations are converted to use GOT_PCREL34 addressing. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [mpe: Some coding style & formatting fixups] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-7-npiggin@gmail.com
-
Nicholas Piggin authored
PC-Relative or PCREL addressing is an extension to the ELF ABI which uses Power ISA v3.1 PC-relative instructions to calculate addresses, rather than the traditional TOC scheme. Add an option to build vmlinux using pcrel addressing. Modules continue to use TOC addressing. - TOC address helpers and r2 are poisoned with -1 when running vmlinux. r2 could be used for something useful once things are ironed out. - Assembly must call C functions with @notoc annotation, or the linker complains aobut a missing nop after the call. This is done with the CFUNC macro introduced earlier. - Boot: with the exception of prom_init, the execution branches to the kernel virtual address early in boot, before any addresses are generated, which ensures 34-bit pcrel addressing does not miss the high PAGE_OFFSET bits. TOC relative addressing has a similar requirement. prom_init does not go to the virtual address and its addresses should not carry over to the post-prom kernel. - Ftrace trampolines are converted from TOC addressing to pcrel addressing, including module ftrace trampolines that currently use the kernel TOC to find ftrace target functions. - BPF function prologue and function calling generation are converted from TOC to pcrel. - copypage_64.S has an interesting problem, prefixed instructions have alignment restrictions so the linker can add padding, which makes the assembler treat the difference between two local labels as non-constant even if alignment is arranged so padding is not required. This may need toolchain help to solve nicely, for now move the prefix instruction out of the alternate patch section to work around it. This reduces kernel text size by about 6%. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-6-npiggin@gmail.com
-
Nicholas Piggin authored
This macro is to be used in assembly where C functions are called. pcrel addressing mode requires branches to functions with a localentry value of 1 to have either a trailing nop or @notoc. This macro permits the latter without changing callers. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [mpe: Add dummy definitions to fix selftests build] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-5-npiggin@gmail.com
-
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 <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-3-npiggin@gmail.com
-
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: Nicholas Piggin <npiggin@gmail.com> [mpe: Retain relative_toc call for start_initialization_book3e] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-2-npiggin@gmail.com
-
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: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-14-pali@kernel.org
-
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 <pali@kernel.org> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-13-pali@kernel.org
-
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 <pali@kernel.org> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-12-pali@kernel.org
-
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 <pali@kernel.org> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-11-pali@kernel.org
-
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 <pali@kernel.org> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> [mpe: Fix some coding style warnings in the moved code] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-10-pali@kernel.org
-
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 <pali@kernel.org> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-9-pali@kernel.org
-
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: Pali Rohár <pali@kernel.org> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-8-pali@kernel.org
-
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 <christophe.leroy@csgroup.eu> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-7-pali@kernel.org
-
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 <christophe.leroy@csgroup.eu> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-6-pali@kernel.org
-
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 <christophe.leroy@csgroup.eu> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-5-pali@kernel.org
-
Christophe Leroy authored
No need to BUG() in case mpic_alloc() fails. Use WARN_ON(). Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-4-pali@kernel.org
-
Christophe Leroy authored
Reduce number of lines in the call to mpic_alloc(). Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-3-pali@kernel.org
-
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: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408140122.25293-2-pali@kernel.org
-
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 <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230409000812.18904-9-pali@kernel.org
-
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 <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230409000812.18904-8-pali@kernel.org
-
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 <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230409000812.18904-7-pali@kernel.org
-
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 <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230409000812.18904-6-pali@kernel.org
-
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 <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230409000812.18904-5-pali@kernel.org
-
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 <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230409000812.18904-4-pali@kernel.org
-
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: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230409000812.18904-3-pali@kernel.org
-
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: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230409000812.18904-2-pali@kernel.org
-
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: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230407040909.230998-1-npiggin@gmail.com
-
- 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: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230407040924.231023-1-npiggin@gmail.com
-
- 11 Apr, 2023 9 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: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230406-wundef-thread_shift_booke-v1-1-8deffa4d84f9@kernel.org
-
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 <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230325122904.2375060-9-npiggin@gmail.com
-
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 <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230325122904.2375060-8-npiggin@gmail.com
-
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 <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230325122904.2375060-7-npiggin@gmail.com
-
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 <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230325122904.2375060-6-npiggin@gmail.com
-
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 <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230325122904.2375060-5-npiggin@gmail.com
-
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 <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230325122904.2375060-4-npiggin@gmail.com
-
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 <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230325122904.2375060-3-npiggin@gmail.com
-
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: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230325122904.2375060-2-npiggin@gmail.com
-