- 14 Jun, 2023 14 commits
-
-
Nicholas Piggin authored
More some 64-bit specifics out from the function epilogue and rearrange this to be a bit neater, use 32-bit mem ops for CR save/restore, and change some register numbers. This is preparation to consolidate 32-bit and 64-bit switch code. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230606132447.315714-3-npiggin@gmail.com
-
Nicholas Piggin authored
The large hunk of SLB pinning in _switch asm code makes it more difficult to see everything else that's going on. It is a less important path now, so icache and fetch footprint overhead can be avoided. Move context switch stack SLB pinning out of line. Signed-off-by:
-
Nicholas Piggin authored
LLVM assembler does not recognise 3-operand cmpi, use cmpwi. Signed-off-by:
-
Nicholas Piggin authored
ELFv2 was introduced together with little-endian. ELFv1 with LE has never been a thing. The GNU toolchain can create such a beast, but anyone doing that is a maniac who needs to be stopped so I consider this patch a feature. Signed-off-by:
-
Nicholas Piggin authored
-mprofile-kernel is an optimised calling convention for mcount that Linux has only implemented with the ELFv2 ABI, so it was disabled for big endian kernels. However it does work with ELFv2 big endian, so let's allow that if the compiler supports it. Acked-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Suggested-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
-
Nicholas Piggin authored
All supported toolchains now support ELFv2 on big-endian, so flip the default on this and hide the option behind EXPERT for the purpose of bug hunting. Signed-off-by:
-
Nicholas Piggin authored
The LLVM linker does not support ELFv1 at all, so BE kernels must be built with ELFv2. The LLD version check was added to be conservative, LLD simply fails to link ELFv1 entirely, effectively requiring LLD >= 15 and ELFv2 for BE builds. Instead remove that restriction until proven otherwise (LLD 14.0 links a booting ELFv2 BE vmlinux for me). The minimum GNU binutils has increased such that ELFv2 is always supported, so remove that check while we're here. Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Tested-by:
-
Nicholas Piggin authored
x86 removed -pipe in commit 437e88ab ("x86/build: Remove -pipe from KBUILD_CFLAGS") and the newer arm64 and riscv seem to have never used it, so that seems to be the way the world's going. Compile performance building defconfig on a POWER10 PowerNV system was in the noise after 10 builds each. No point in adding options unless they help something, so remove it. Signed-off-by:
-
Nicholas Piggin authored
Tidy pass over boot Makefile. Move variables together where possible. Signed-off-by:
-
Nicholas Piggin authored
BOOTCFLAGS no longer contains anything that BOOTASFLAGS needs (except -pipe). Separate them to avoid fragility with cross-contamination of flags which has caused several build problems. Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/lkml/CAHk-=whyWUdJDeOBN1hRWYSkQkvzYiQ5RbSW5rJjExgnbSNX9Q@mail.gmail.com/Signed-off-by:
-
Nicholas Piggin authored
Add BOOTCPPFLAGS variable for the CPP options required by C and AS. Signed-off-by:
-
Nicholas Piggin authored
Add BOOTTARGETFLAGS variable with target / ABI options common to CFLAGS and AFLAGS. Signed-off-by:
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f4 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f4 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
- 09 Jun, 2023 11 commits
-
-
Christophe Leroy authored
Looking at generated code for handle_signal32() shows calls to a function called __unsafe_save_user_regs.constprop.0 while user access is open. And that __unsafe_save_user_regs.constprop.0 function has two nops at the begining, allowing it to be traced, which is unexpected during user access open window. The solution could be to mark __unsafe_save_user_regs() no trace, but to be on the safe side the most efficient is to flag it __always_inline as already done for function __unsafe_restore_general_regs(). The function is relatively small and only called twice, so the size increase will remain in the noise. Do the same with save_tm_user_regs_unsafe() as it may suffer the same issue. Fixes: ef75e731 ("powerpc/signal32: Transform save_user_regs() and save_tm_user_regs() in 'unsafe' version") Signed-off-by:
-
Christophe Leroy authored
A disassembly of interrupt_exit_kernel_prepare() shows a useless read of MSR register. This is shown by r9 being re-used immediately without doing anything with the value read. c000e0e0: 60 00 00 00 nop c000e0e4: 7d 3a c2 a6 mfmd_ap r9 c000e0e8: 7d 20 00 a6 mfmsr r9 c000e0ec: 7c 51 13 a6 mtspr 81,r2 c000e0f0: 81 3f 00 84 lwz r9,132(r31) c000e0f4: 71 29 80 00 andi. r9,r9,32768 This is due to the use of local_irq_save(). The flags read by local_irq_save() are never used, use local_irq_disable() instead. Fixes: 13799748 ("powerpc/64: use interrupt restart table to speed up return from interrupt") Signed-off-by:
-
Christophe Leroy authored
The following boottime error is encountered with SMP kernel: kcsan: improperly instrumented type=(0): arch_spin_unlock(&arch_spinlock) kcsan: improperly instrumented type=(0): spin_unlock(&test_spinlock) kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE): arch_spin_unlock(&arch_spinlock) kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE): spin_unlock(&test_spinlock) kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE | KCSAN_ACCESS_COMPOUND): arch_spin_unlock(&arch_spinlock) kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE | KCSAN_ACCESS_COMPOUND): spin_unlock(&test_spinlock) kcsan: selftest: test_barrier failed kcsan: selftest: 2/3 tests passed Kernel panic - not syncing: selftests failed Properly instrument arch_spin_unlock() with kcsan_mb(). Signed-off-by:
Marco Elver <elver@google.com> Signed-off-by:
-
Christophe Leroy authored
The stubs were provided by commit 725aea87 ("xtensa: enable KCSAN") to make linker happy allthought they are not meant to be used at all. KCSAN core has been fixed to not require them anymore on 32 bits architectures. Then they can be removed. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Acked-by:
-
Rohan McLure authored
Enable HAVE_ARCH_KCSAN on all powerpc platforms, permitting use of the kernel concurrency sanitiser through the CONFIG_KCSAN_* kconfig options. Boots and passes selftests on 32-bit and 64-bit platforms. See documentation in Documentation/dev-tools/kcsan.rst for more information. Signed-off-by:
Rohan McLure <rmclure@linux.ibm.com> Signed-off-by:
-
Christophe Leroy authored
Activating KCSAN on a 32 bits architecture leads to the following link-time failure: LD .tmp_vmlinux.kallsyms1 powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_load': kernel/kcsan/core.c:1273: undefined reference to `__atomic_load_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_store': kernel/kcsan/core.c:1273: undefined reference to `__atomic_store_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_exchange': kernel/kcsan/core.c:1273: undefined reference to `__atomic_exchange_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_add': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_add_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_sub': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_sub_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_and': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_and_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_or': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_or_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_xor': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_xor_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_nand': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_nand_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_compare_exchange_strong': kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_compare_exchange_weak': kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_compare_exchange_val': kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8' 32 bits architectures don't have 64 bits atomic builtins. Only include DEFINE_TSAN_ATOMIC_OPS(64) on 64 bits architectures. Fixes: 0f8ad5f2 ("kcsan: Add support for atomic builtins") Suggested-by: -
Randy Dunlap authored
When CONFIG_SMP is not set, CONFIG_BROKEN_ON_SMP is set, and CONFIG_PCI is not set, there can be a kconfig warning: WARNING: unmet direct dependencies detected for PPC_INDIRECT_PCI Depends on [n]: PCI [=n] Selected by [y]: - MPC10X_BRIDGE [=y] To fix that, make the selects of MPC10X_BRIDGE be conditional on PCI and use "imply" instead of "select". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Suggested-by: Michael Ellerman <mpe@ellerman.id.au> # use "imply" Signed-off-by:
-
Nicholas Piggin authored
Michael is merging KVM PPC patches via the powerpc tree and KVM topic branches. He doesn't necessarily have time to be across all of KVM so is reluctant to call himself maintainer, but for the mechanics of how patches flow upstream, it is maintained and does make sense to have some contact people in MAINTAINERS. So add Michael Ellerman as KVM PPC maintainer and myself as reviewer. Split out the subarchs that don't get so much attention. Signed-off-by:
-
Michael Ellerman authored
Ben no longer has time to do any maintenance of the powermac code. Mark it as orphan. Signed-off-by:
-
Michael Ellerman authored
The powerpc section has a "F:" entry for drivers/macintosh, matching all files in or below drivers/macintosh. That is correct for the most part, but there are a couple of m68k-only drivers in the directory, so exclude those. Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Michael Ellerman authored
Merge our fixes branch, in particular to bring in the change to arch/powerpc/boot/Makefile, which is depended upon by a subsequent series.
-
- 30 May, 2023 3 commits
-
-
Maninder Singh authored
kallsyms_lookup() which in turn calls kallsyms_lookup_buildid() writes to index "KSYM_NAME_LEN - 1". Thus the array passed as namebuf to kallsyms_lookup() should be KSYM_NAME_LEN in size. In xmon.c the array was defined to be "128" bytes directly, without using KSYM_NAME_LEN. Commit b8a94bfb ("kallsyms: increase maximum kernel symbol length to 512") changed the value to 512, but missed updating the xmon code. Fixes: b8a94bfb ("kallsyms: increase maximum kernel symbol length to 512") Cc: stable@vger.kernel.org # v6.1+ Co-developed-by:
Onkarnath <onkarnath.1@samsung.com> Signed-off-by:
Maninder Singh <maninder1.s@samsung.com> [mpe: Tweak change log wording and fix commit reference] Signed-off-by:
-
Gaurav Batra authored
Currently in tce_freemulti_pSeriesLP() there is no limit on how many TCEs are passed to the H_STUFF_TCE hcall. This has not caused an issue until now, but newer firmware releases have started enforcing a limit of 512 TCEs per call. The limit is correct per the specification (PAPR v2.12 § 14.5.4.2.3). The code has been in it's current form since it was initially merged. Cc: stable@vger.kernel.org Signed-off-by:
Gaurav Batra <gbatra@linux.vnet.ibm.com> Reviewed-by:
Brian King <brking@linux.vnet.ibm.com> [mpe: Tweak change log wording & add PAPR reference] Signed-off-by:
-
Michael Ellerman authored
The recently added P10 AES/GCM code added some files containing CRYPTOGAMS perl-asm code which are near duplicates of the p8 files found in drivers/crypto/vmx. In particular the newly added files produce functions with identical names to the existing code. When the kernel is built with CONFIG_CRYPTO_AES_GCM_P10=y and CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y that leads to link errors, eg: ld: drivers/crypto/vmx/aesp8-ppc.o: in function `aes_p8_set_encrypt_key': (.text+0xa0): multiple definition of `aes_p8_set_encrypt_key'; arch/powerpc/crypto/aesp8-ppc.o:(.text+0xa0): first defined here ... ld: drivers/crypto/vmx/ghashp8-ppc.o: in function `gcm_ghash_p8': (.text+0x140): multiple definition of `gcm_ghash_p8'; arch/powerpc/crypto/ghashp8-ppc.o:(.text+0x2e4): first defined here Fix it for now by renaming the newly added files and functions to use "p10" instead of "p8" in the names. Fixes: 45a4672b ("crypto: p10-aes-gcm - Update Kconfig and Makefile") Tested-by:
Vishal Chourasia <vishalc@linux.ibm.com> Signed-off-by:
-
- 21 May, 2023 1 commit
-
-
Michael Ellerman authored
Commit 1e8fed87 ("powerpc: drop ranges for definition of ARCH_FORCE_MAX_ORDER") removed the limits on the possible values for ARCH_FORCE_MAX_ORDER. However removing the ranges entirely causes some common work flows to break. For example building a defconfig (which uses 64K pages), changing the page size to 4K, and rebuilding used to work, because ARCH_FORCE_MAX_ORDER would be clamped to 12 by the ranges. With the ranges removed it creates a kernel that builds but crashes at boot: kernel BUG at mm/huge_memory.c:470! Oops: Exception in kernel mode, sig: 5 [#1] ... NIP hugepage_init+0x9c/0x278 LR do_one_initcall+0x80/0x320 Call Trace: do_one_initcall+0x80/0x320 kernel_init_freeable+0x304/0x3ac kernel_init+0x30/0x1a0 ret_from_kernel_user_thread+0x14/0x1c The reasoning for removing the ranges was that some of the values were too large. So take that into account and limit the maximums to 10 which is the default max, except for the 4K case which uses 12. Fixes: 1e8fed87 ("powerpc: drop ranges for definition of ARCH_FORCE_MAX_ORDER") Signed-off-by:
-
- 16 May, 2023 3 commits
-
-
Gaurav Batra authored
For an SR-IOV device, while enabling DDW, a new table is created and added at index 1 in the group. In the below 2 scenarios, the table is incorrectly referenced at index 0 (which is where the table is for default DMA window). 1. When adding DDW This issue is exposed with "slub_debug". Error thrown out from dma_iommu_dma_supported() Warning: IOMMU offset too big for device mask mask: 0xffffffff, table offset: 0x800000000000000 2. During Dynamic removal of the PCI device. Error is from iommu_tce_table_put() since a NULL table pointer is passed in. Fixes: 381ceda8 ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by:
-
Gaurav Batra authored
When DMA window is backed by 2MB TCEs, the DMA address for the mapped page should be the offset of the page relative to the 2MB TCE. The code was incorrectly setting the DMA address to the beginning of the TCE range. Mellanox driver is reporting timeout trying to ENABLE_HCA for an SR-IOV ethernet port, when DMA window is backed by 2MB TCEs. Fixes: 38727311 ("powerps/pseries/dma: Add support for 2M IOMMU page size") Cc: stable@vger.kernel.org # v5.16+ Signed-off-by:
Greg Joyce <gjoyce@linux.vnet.ibm.com> Reviewed-by:
-
Jason Gunthorpe authored
Now that power calls iommu_device_register() and populates its groups using iommu_ops->device_group it should not be calling iommu_group_remove_device(). The core code owns the groups and all the other related iommu data, it will clean it up automatically. Remove the bus notifiers and explicit calls to iommu_group_remove_device(). Fixes: a9409044 ("powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains") Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com> Signed-off-by:
-
- 15 May, 2023 5 commits
-
-
Uwe Kleine-König authored
While mpc5200b.dtsi contains a device that this driver can bind to, the only purpose of a bound device is to be used by the four exported functions mpc52xx_lpbfifo_submit(), mpc52xx_lpbfifo_abort(), mpc52xx_lpbfifo_poll() and mpc52xx_lpbfifo_start_xfer(). However there are no callers to this function and so the driver is effectively superfluous and can be deleted. Also drop some defines and a struct from <asm/mpc52xx.h> that are unused now together with the declarations of the four mentioned functions. Signed-off-by:
-
Tom Rix authored
For ppc64, gcc with W=1 reports arch/powerpc/platforms/cell/spu_base.c:330:17: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 330 | ; | ^ arch/powerpc/platforms/cell/spu_base.c:333:17: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 333 | ; | ^ These if-checks do not do anything so remove them. Signed-off-by:Tom Rix <trix@redhat.com> Fixes: 67207b96 ("[PATCH] spufs: The SPU file system, base") Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Randy Dunlap authored
Drop an unused and empty "config" entry for PPC_86xx. It has no keyword entries under it and the following line's "menuconfig" for the same Kconfig symbol is what kconfig uses. Fixes: d8267c1a ("powerpc: Add 82xx/83xx/86xx to 6xx Multiplatform") Signed-off-by:
-
Michael Ellerman authored
When VSX is disabled, eg. microwatt_defconfig, the build fails with: In function ‘enable_kernel_vsx’, inlined from ‘vsx_begin’ at arch/powerpc/crypto/aes-gcm-p10-glue.c:68:2, inlined from ‘p10_aes_gcm_crypt.constprop’ at arch/powerpc/crypto/aes-gcm-p10-glue.c:244:2: ... arch/powerpc/include/asm/switch_to.h:86:9: note: in expansion of macro ‘BUILD_BUG’ 86 | BUILD_BUG(); | ^~~~~~~~~ Fix it by making the p10-aes-gcm code depend on VSX. Signed-off-by: -
Hari Bathini authored
Since commit 85e03115 ("powerpc/bpf: Perform complete extra passes to update addresses"), two additional passes are performed to avoid space and CPU time wastage on powerpc. But these extra passes led to WARN_ON_ONCE() hits in bpf_add_extable_entry() as extable entries are populated again, during the extra pass, without resetting the index. Fix it by resetting entry index before repopulating extable entries, if and when there is an additional pass. Fixes: 85e03115 ("powerpc/bpf: Perform complete extra passes to update addresses") Cc: stable@vger.kernel.org # v6.3+ Signed-off-by:
Hari Bathini <hbathini@linux.ibm.com> Reviewed-by:
-
- 14 May, 2023 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxlLinus Torvalds authored
Pull compute express link fixes from Dan Williams: - Fix a compilation issue with DEFINE_STATIC_SRCU() in the unit tests - Fix leaking kernel memory to a root-only sysfs attribute * tag 'cxl-fixes-6.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl: cxl: Add missing return to cdat read error path tools/testing/cxl: Use DEFINE_STATIC_SRCU()
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull parisc architecture fixes from Helge Deller: - Fix encoding of swp_entry due to added SWP_EXCLUSIVE flag - Include reboot.h to avoid gcc-12 compiler warning * tag 'parisc-for-6.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix encoding of swp_entry due to added SWP_EXCLUSIVE flag parisc: kexec: include reboot.h
-
