- 03 Mar, 2024 14 commits
-
-
Christophe Leroy authored
Most probe functions that do not use the 'compatible' string do nothing else than checking whether the machine is compatible with one of the strings in a NULL terminated table of strings. Define that table of strings in ppc_md structure and check it directly from probe_machine() instead of using ppc_md.probe() for that. Keep checking in ppc_md.probe() only for more complex probing. All .compatible could be replaced with a single element NULL terminated list but that's not worth the churn. Can be do incrementaly in follow-up patches. Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231214103152.12269-4-mpe@ellerman.id.au
-
Christophe Leroy authored
of_machine_compatible_match() works with a table of strings. of_machine_is_compatible() is a simplier version with only one string. Re-implement of_machine_is_compatible() by setting a table of strings with a single string then using of_machine_compatible_match(). Suggested-by:
Rob Herring <robh+dt@kernel.org> Signed-off-by:
-
Michael Ellerman authored
of_machine_is_compatible() currently returns a positive integer if it finds a match. However none of the callers ever check the value, they all treat it as a true/false. So change of_machine_is_compatible() to return bool, which will allow the implementation to be changed in a subsequent patch. Suggested-by:
-
Michael Ellerman authored
We have of_machine_is_compatible() to check if a machine is compatible with a single compatible string. However some code is able to support multiple compatible boards, and so wants to check for one of many compatible strings. So add of_machine_compatible_match() which takes a NULL terminated array of compatible strings to check against the root node's compatible property. Compared to an open coded match this is slightly more self documenting, and also avoids the caller needing to juggle the root node either directly or via of_find_node_by_path(). Signed-off-by:
-
Michael Ellerman authored
32-bit powerpc kernels can be built for one of 5 sub-arches, see Kconfig.cputype: PPC_BOOK3S_32: "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx" PPC_85xx: "Freescale 85xx" PPC_8xx: "Freescale 8xx" 40x: "AMCC 40x" 44x: "AMCC 44x, 46x or 47x" By default none of these are built for a plain allmodconfig build, because it selects PPC64 which builds a 64-bit kernel. There is already a ppc32_allmodconfig, which enables PPC_BOOK3S_32. Add similar targets for the other 32-bit sub-arches to increase build coverage: ppc40x_allmodconfig ppc44x_allmodconfig ppc8xx_allmodconfig ppc85xx_allmodconfig Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Michael Ellerman authored
These functions can all be static, make them so, which also fixes no previous prototype warnings. Signed-off-by:
-
Michael Ellerman authored
simple_realloc() frees the original buffer (ptr) even if the reallocation failed. Fix it to behave like standard realloc() and only free the original buffer if the reallocation succeeded. Signed-off-by:
-
Li zeming authored
simple_malloc() will return NULL when there is not enough memory left. Check pointer 'new' before using it to copy the old data. Signed-off-by:
Li zeming <zeming@nfschina.com> [mpe: Reword subject, use change log from Christophe] Signed-off-by:
-
Qiheng Lin authored
`buf` is allocated in papr_get_attr(), and krealloc() of `buf` could fail. We need to free the original `buf` in the case of failure. Fixes: 3c14b734 ("powerpc/pseries: Interface to represent PAPR firmware attributes") Signed-off-by:
Qiheng Lin <linqiheng@huawei.com> Signed-off-by:
-
Sathvika Vasireddy authored
objtool throws the following warning: arch/powerpc/kexec/relocate_32.o: warning: objtool: .text+0x2bc: unannotated intra-function call Fix this warning by annotating intra-function call, using ANNOTATE_INTRA_FUNCTION_CALL macro, to indicate that the branch target is valid. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Sathvika Vasireddy <sv@linux.ibm.com> Signed-off-by:
-
Michael Ellerman authored
Fix a (randconfig) kconfig warning by correcting the select statement: WARNING: unmet direct dependencies detected for ADB_CUDA Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && !PPC_PMAC64 [=n] Selected by [y]: - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET [=y] && PPC32 [=y] The PPC32 isn't needed because ADB depends on (PPC_PMAC && PPC32). Fixes: a3ef2fef ("powerpc/32: Add dependencies of POWER_RESET for pmac32") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Tested: Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Brian King authored
Some devices are not capable of addressing 64 bits via DMA, which includes MSI-X vectors. This allows us to ensure these devices use MSI-X vectors in 32 bit space. Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
-
Christophe Leroy authored
set_memory_p() and set_memory_np() can fail. As mentioned in linux/mm.h: /* * To support DEBUG_PAGEALLOC architecture must ensure that * __kernel_map_pages() never fails */ So panic in case set_memory_p() or set_memory_np() fail in __kernel_map_pages(). Link: https://github.com/KSPP/linux/issues/7Signed-off-by:
-
Christophe Leroy authored
__kernel_map_pages() is almost identical for PPC32 and RADIX. Refactor it. On PPC32 it is not needed for KFENCE, but to keep it simple just make it similar to PPC64. Move the prototype of hash__kernel_map_pages() into mmu_decl.h to allow IS_ENABLED() to work on 32-bit. Signed-off-by:
-
- 22 Feb, 2024 10 commits
-
-
Christophe Leroy authored
set_memory_rox() can fail. In case it fails, free allocated memory and return NULL. Link: https://github.com/KSPP/linux/issues/7Signed-off-by:
-
Christophe Leroy authored
Same as x86 and s390, add set_memory_rox() to avoid doing one pass with set_memory_ro() and a second pass with set_memory_x(). See commit 60463628 ("x86/mm: Implement native set_memory_rox()") and commit 22e99fa5 ("s390/mm: implement set_memory_rox()") for more information. Signed-off-by:
-
Christophe Leroy authored
There is a nice macro to check user mode. Use it instead of open coding anding with MSR_PR to increase readability and avoid having to comment what that anding is for. Signed-off-by:
-
Christophe Leroy authored
'perf list' on powerpc 8xx shows an event named "1:hash_fault". This event is pointless because trace_hash_fault() is called only from mm/book3s64/hash_utils.c Only define it when CONFIG_PPC_64S_HASH_MMU is selected. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
- 21 Feb, 2024 9 commits
-
-
Geoff Levand authored
This reverts commit 482b718a. The preceding commits by Nicholas Piggin enable PS3 support for ELFv2, so there's no need to disable it for PS3 anymore. Signed-off-by:
Geoff Levand <geoff@infradead.org> Signed-off-by:
-
Nicholas Piggin authored
The PS3 hcall assembly code makes ad-hoc stack frames that don't have a back-chain pointer or meet other requirements like minimum frame size. This probably confuses stack unwinders. Give all hcalls a real stack frame. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Tested-by:
-
Nicholas Piggin authored
The LRSAVE constant is required for assembly compiled for both 32-bit and 64-bit, because the value differs there. PS3 is 64-bit only so this is a noop, but it is nice to abstract stack frame offsets. Signed-off-by:
-
Nicholas Piggin authored
Stack-passed parameters begin at a different offset in the caller's stack in the ELFv2 ABI. Reported-by:
-
Nicholas Piggin authored
PAPR will define a new ibm,pi-features bit which says that doorbells should not be used even on architectures where they exist. This could be because they are emulated and slower than using the interrupt controller directly for IPIs. Wire this bit into the pi-features parser to clear CPU_FTR_DBELL, and ensure CPU_FTR_DBELL is not in CPU_FTRS_ALWAYS. Signed-off-by:
Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by:
-
Nicholas Piggin authored
When a new ibm,pa/pi-features bit is introduced that is intended to apply to existing systems and features, it may have an "inverted" meaning (i.e., bit clear => feature available; bit set => unavailable). Depending on the nature of the feature, this may give the best backward compatibility result where old firmware will continue to have that bit clear and therefore the feature available. The 'invert' modifier presumably was introduced for this type of feature bit. However it invert will set the feature if the bit is clear, which prevents it being used in the situation where an old CPU lacks a feature that a new CPU has, then a new firmware comes out to disable that feature on the new CPU if the bit is set. Adding an 'invert' entry for that feature would incorrectly enable it for the old CPU. So add a 'clear' modifier that clears the feature if the bit is set, but it does not set the feature if the bit is clear. The feature is expected to be set in the cpu table. This replaces the 'invert' modifier, which is unused since commit 7d470345 ("powerpc/feature: Remove CPU_FTR_NODSISRALIGN"). Signed-off-by:
-
Madhavan Srinivasan authored
Base enablement patch to register performance monitoring hardware support for Power11. Most of fields are copied from power10_pmu struct for power11_pmu struct. Signed-off-by:
Madhavan Srinivasan <maddy@linux.ibm.com> Signed-off-by:
-
Madhavan Srinivasan authored
Add CPU table entries for raw and architected mode. Most fields are copied from the Power10 table entries. CPU, MMU and user (ELF_HWCAP) features are unchanged vs P10. However userspace can detect P11 because the AT_PLATFORM value changes to "power11". The logical PVR value of 0x0F000007, passed to firmware via the ibm_arch_vec, indicates the kernel can support a P11 compatible CPU, which means at least ISA v3.1 compliant. Signed-off-by:
-
Shrikanth Hegde authored
When an ifdef is used in the below manner, second one could be considered as duplicate. ifdef DEFINE_A ...code block... ifdef DEFINE_A <-- This is a duplicate. ...code block... endif else ifndef DEFINE_A <-- This is also duplicate. ...code block... endif endif More details about the script and methods used to find these code patterns are in cover letter of [1]. Few places in arch/powerpc where this pattern was seen: paca.h: Hunk1: Code is under check of CONFIG_PPC64 from line 13, hence the second CONFIG_PPC64 at line 166 is a duplicate. Hunk2: CONFIG_PPC_BOOK3S_64 was defined back to back. Merged the two ifdefs. asm-offsets.c: Code is under check of CONFIG_PPC64 from line 176 hence second CONFIG_PPC64 at line 249 is a duplicate. powermac/feature.c: #ifndef CONFIG_PPC64 is used at line 2066. And then in #else again #ifdef CONFIG_PPC64 is used. Which is a duplicate since in #else means CONFIG_PPC64 is defined. xmon.c: Code is under the check of CONFIG_SMP from line 521 hence the same check of CONFIG_SMP at line 646 is a duplicate. No functional change is intended here. It only aims to improve code readability. [1] https://lore.kernel.org/all/20240118080326.13137-1-sshegde@linux.ibm.com/Signed-off-by:
Shrikanth Hegde <sshegde@linux.ibm.com> Signed-off-by:
-
- 19 Feb, 2024 1 commit
-
-
Masahiro Yamada authored
Commit 2fb857bc ("powerpc/kcsan: Add exclusions from instrumentation") added KCSAN_SANITIZE_early_64.o to arch/powerpc/kernel/Makefile, while it does not compile early_64.o. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
- 16 Feb, 2024 6 commits
-
-
Peter Bergner authored
The powerpc toolchain keeps a copy of the HWCAP bit masks in the TCB for fast access by the __builtin_cpu_supports() built-in function. The TCB space for the HWCAP entries - which are created in pairs - is an ABI extension, so waiting to create the space for HWCAP3 and HWCAP4 until they are needed is problematic. Define AT_HWCAP3 and AT_HWCAP4 in the generic uapi header so they can be used in glibc to reserve space in the powerpc TCB for their future use. I scanned through the Linux and GLIBC source codes looking for unused AT_* values and 29 and 30 did not seem to be used, so they are what I went with. Signed-off-by:
Peter Bergner <bergner@linux.ibm.com> Acked-by:
Adhemerval Zanella <adhemerval.zanella@linaro.org> Acked-by:
Szabolcs Nagy <szabolcs.nagy@arm.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
