- Mar 07, 2024
-
-
Michael Ellerman authored
Building eg. 83xx/mpc832x_rdb_defconfig with FPU=n, fails with: arch/powerpc/platforms/83xx/suspend.c: In function 'mpc83xx_suspend_enter': arch/powerpc/platforms/83xx/suspend.c:209:17: error: implicit declaration of function 'enable_kernel_fp' 209 | enable_kernel_fp(); Fix it by providing an enable_kernel_fp() stub for FPU=n builds, which allows using IS_ENABLED(CONFIG_PPC_FPU) around the call to enable_kernel_fp(). Signed-off-by:Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240306125853.3714578-2-mpe@ellerman.id.au
-
Michael Ellerman authored
With CONFIG_BUG=n, the 64-bit Book3S build fails with: arch/powerpc/include/asm/book3s/64/pgtable-64k.h: In function 'get_hugepd_cache_index': arch/powerpc/include/asm/book3s/64/pgtable-64k.h:51:1: error: no return statement in function returning non-void Currently the body of the function is just BUG(), so when CONFIG_BUG=n it is an empty function, leading to the error. get_hugepd_cache_index() should never be called, the only call is behind an is_hugepd() check, which is always false for this configuration. Instead mark it as always inline, and change the BUG() to BUILD_BUG(). That should allow the compiler to see that the function is never called, and therefore that it never returns, fixing the build error. Signed-off-by:
-
- Mar 06, 2024
-
-
Michael Ellerman authored
The 44x/warp_defconfig build fails with: arch/powerpc/platforms/44x/warp.c:109:15: error: variable ‘warp_gpio_leds’ has initializer but incomplete type 109 | static struct platform_device warp_gpio_leds = { | ^~~~~~~~~~~~~~~ Fix it by including platform_device.h. Fixes: ef175b29 ("of: Stop circularly including of_device.h and of_platform.h") Signed-off-by: -
Michael Ellerman authored
These functions can all be static. Make them so. That also fixes no previous prototype warnings: arch/powerpc/platforms/amigaone/setup.c:28:6: error: no previous prototype for 'amigaone_show_cpuinfo' arch/powerpc/platforms/amigaone/setup.c:68:13: error: no previous prototype for 'amigaone_setup_arch' arch/powerpc/platforms/amigaone/setup.c:86:13: error: no previous prototype for 'amigaone_init_IRQ' arch/powerpc/platforms/amigaone/setup.c:126:17: error: no previous prototype for 'amigaone_restart' Signed-off-by:
-
Michael Ellerman authored
Move the prototypes into mpc10x.h which is included by all the relevant C files, fixes: arch/powerpc/platforms/embedded6xx/ls_uart.c:59:6: error: no previous prototype for 'avr_uart_configure' arch/powerpc/platforms/embedded6xx/ls_uart.c:82:6: error: no previous prototype for 'avr_uart_send' Signed-off-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the adb_dev_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
"Ricardo B. Marliere" <ricardo@marliere.net> Signed-off-by:
-
Nathan Chancellor authored
arch/powerpc/lib/xor_vmx.o is built with '-msoft-float' (from the main powerpc Makefile) and '-maltivec' (from its CFLAGS), which causes an error when building with clang after a recent change in main: error: option '-msoft-float' cannot be specified with '-maltivec' make[6]: *** [scripts/Makefile.build:243: arch/powerpc/lib/xor_vmx.o] Error 1 Explicitly add '-mhard-float' before '-maltivec' in xor_vmx.o's CFLAGS to override the previous inclusion of '-msoft-float' (as the last option wins), which matches how other areas of the kernel use '-maltivec', such as AMDGPU. Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/1986 Link: https://github.com/llvm/llvm-project/commit/4792f912b232141ecba4cbae538873be3c28556c Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
Michael Ellerman authored
mfpmr() needs to be marked always inline, otherwise the compiler will complain that the rn argument can't be passed to the asm block as an integer: arch/powerpc/include/asm/reg_fsl_emb.h:18:9: warning: 'asm' operand 1 probably does not match constraints 18 | asm (".machine push; " | ^~~ arch/powerpc/include/asm/reg_fsl_emb.h:18:9: error: impossible constraint in 'asm' Mark mtpmr() always inline also to avoid any future problems with it. Fixes: f01dbd73 ("powerpc/fsl: Modernise mt/mfpmr") Reported-by:kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202403051835.iqLGz996-lkp@intel.com/ Signed-off-by:
-
- Mar 03, 2024
-
-
Christophe Leroy authored
cpu-as-y is there to force assembler building options. But there is no need for that. GCC is passed the necessary options and it automatically pass the appropriate option to GAS. GCC is given -maltivec when relevant, so no need for -Wa,-maltivec either. And -Wa,-many is wrong as it will hide innapropriate instructions. Better to detect them and handle them on a case by case basis. The setting of -Wa,-many was added by commit 960e3002 ("powerpc/Makefile: Fix PPC_BOOK3S_64 ASFLAGS") in order to fix an issue with clang and the passed -Wa,-mpower4 option. But we have now removed it expecting the compiler to automatically pass the proper options and instructions based on -mcpu=power4. Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by:
Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by:
-
Michael Ellerman authored
With the addition of the machine directives, these are no longer simple 1-2 liner macros. So modernise them to be static inlines and use named asm parameters. Acked-by:
-
Michael Ellerman authored
Binutils 2.38 complains about the use of mfpmr when building ppc6xx_defconfig: CC arch/powerpc/kernel/pmc.o {standard input}: Assembler messages: {standard input}:45: Error: unrecognized opcode: `mfpmr' {standard input}:56: Error: unrecognized opcode: `mtpmr' This is because by default the kernel is built with -mcpu=powerpc, and the mt/mfpmr instructions are not defined. It can be avoided by enabling CONFIG_E300C3_CPU, but just adding that to the defconfig will leave open the possibility of randconfig failures. So add machine directives around the mt/mfpmr instructions to tell binutils how to assemble them. Cc: stable@vger.kernel.org Reported-by:Jan-Benedict Glaw <jbglaw@lug-owl.de> Signed-off-by:
-
Michael Ellerman authored
There are multiple decodings for the "dcbt" mnemonic, so the assembler has to pick one. That requires passing -many to the assembler, which is not recommended. Without -many the clang 14 / binutils 2.38 build fails with: arch/powerpc/kernel/exceptions-64s.S:2976: Error: junk at end of line: `0b01010' clang: error: assembler command failed with exit code 1 (use -v to see invocation) Fix it by adding .machine directives around the use of dcbt to specify which encoding is desired. Acked-by:
-
Michael Ellerman authored
There's an almost identical code sequence to specify load/store access hints in __copy_tofrom_user_power7(), copypage_power7() and memcpy_power7(). Move the sequence into a common macro, which is passed the registers to use as they differ slightly. There also needs to be a copy in the selftests, it could be shared in future if the headers are cleaned up / refactored. Signed-off-by:
-
Kunwu Chan authored
This part was commented from commit 6d492ecc ("powerpc/THP: Add code to handle HPTE faults for hugepages") in about 11 years before. If there are no plans to enable this part code in the future, we can remove this dead code and replace with a comment explaining what the dead code was trying to say. Signed-off-by:
Kunwu Chan <chentao@kylinos.cn> Suggested-by:
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org> Signed-off-by:
-
Kajol Jain authored
Running event hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ in one of the system throws below error: ---Logs--- # perf list | grep hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=?/[Kernel PMU event] # perf stat -v -e hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ sleep 2 Using CPUID 00800200 Control descriptor is not initialized Warning: hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ event is not supported by the kernel. failed to read counter hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ Performance counter stats for 'system wide': <not supported> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ 2.000700771 seconds time elapsed The above error is because of the hcall failure as required permission "Enable Performance Information Collection" is not set. Based on current code, single_gpci_request function did not check the error type incase hcall fails and by default returns EINVAL. But we can have other reasons for hcall failures like H_AUTHORITY/H_PARAMETER with detail_rc as GEN_BUF_TOO_SMALL, for which we need to act accordingly. Fix this issue by adding new checks in the single_gpci_request and h_gpci_event_init functions. Result after fix patch changes: # perf stat -e hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ sleep 2 Error: No permission to enable hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ event. Fixes: 220a0c60 ("powerpc/perf: Add support for the hv gpci (get performance counter info) interface") Reported-by:Akanksha J N <akanksha@linux.ibm.com> Signed-off-by:
Kajol Jain <kjain@linux.ibm.com> Signed-off-by:
-
Michael Ellerman authored
Allow a transition from the softirq stack to the hardirq stack when handling a hardirq. Doing so means a hardirq received while deep in softirq processing is less likely to cause a stack overflow of the softirq stack. Previously it wasn't safe to do so because irq_exit() (which initiates softirq processing) was called on the hardirq stack. That was changed in commit 1b1b6a6f ("powerpc: handle irq_enter/ irq_exit in interrupt handler wrappers") and 1346d00e ("powerpc: Don't select HAVE_IRQ_EXIT_ON_IRQ_STACK"). The allowed transitions are now: - process stack -> hardirq stack - process stack -> softirq stack - process stack -> softirq stack -> hardirq stack Reviewed-by:
-
Christophe Leroy authored
Replace all usages of of_root by of_find_node_by_path("/") Signed-off-by:Rob Herring <robh@kernel.org> Signed-off-by:
-
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 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:
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/7 Signed-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:
-
- Feb 22, 2024
-
-
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/7 Signed-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:
-
