summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2024-09-10powerpc/pseries/eeh: Fix pseries_eeh_err_injectNarayana Murty N3-5/+44
VFIO_EEH_PE_INJECT_ERR ioctl is currently failing on pseries due to missing implementation of err_inject eeh_ops for pseries. This patch implements pseries_eeh_err_inject in eeh_ops/pseries eeh_ops. Implements support for injecting MMIO load/store error for testing from user space. The check on PCI error type (bus type) code is moved to platform code, since the eeh_pe_inject_err can be allowed to more error types depending on platform requirement. Removal of the check for 'type' in eeh_pe_inject_err() doesn't impact PowerNV as pnv_eeh_err_inject() already has an equivalent check in place. Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com> Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240909140220.529333-1-nnmlinux@linux.ibm.com
2024-09-09treewide: correct the typo 'retun'WangYuli1-1/+1
There are some spelling mistakes of 'retun' in comments which should be instead of 'return'. Link: https://lkml.kernel.org/r/63D0F870EE8E87A0+20240906054008.390188-1-wangyuli@uniontech.com Signed-off-by: WangYuli <wangyuli@uniontech.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-09-09mm: pass vm_flags to generic_get_unmapped_area()Mark Brown1-2/+2
In preparation for using vm_flags to ensure guard pages for shadow stacks supply them as an argument to generic_get_unmapped_area(). The only user outside of the core code is the PowerPC book3s64 implementation which is trivially wrapping the generic implementation in the radix_enabled() case. No functional changes. Link: https://lkml.kernel.org/r/20240904-mm-generic-shadow-stack-guard-v2-2-a46b8b6dc0ed@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Andreas Larsson <andreas@gaisler.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Chris Zankel <chris@zankel.net> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David S. Miller <davem@davemloft.net> Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Guo Ren <guoren@kernel.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Helge Deller <deller@gmx.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Matt Turner <mattst88@gmail.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Naveen N Rao <naveen@kernel.org> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Rich Felker <dalias@libc.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Vineet Gupta <vgupta@kernel.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: WANG Xuerui <kernel@xen0n.name> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-09-09mm: make arch_get_unmapped_area() take vm_flags by defaultMark Brown16-42/+36
Patch series "mm: Care about shadow stack guard gap when getting an unmapped area", v2. As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow stack guard gap during placement") our current mmap() implementation does not take care to ensure that a new mapping isn't placed with existing mappings inside it's own guard gaps. This is particularly important for shadow stacks since if two shadow stacks end up getting placed adjacent to each other then they can overflow into each other which weakens the protection offered by the feature. On x86 there is a custom arch_get_unmapped_area() which was updated by the above commit to cover this case by specifying a start_gap for allocations with VM_SHADOW_STACK. Both arm64 and RISC-V have equivalent features and use the generic implementation of arch_get_unmapped_area() so let's make the equivalent change there so they also don't get shadow stack pages placed without guard pages. The arm64 and RISC-V shadow stack implementations are currently on the list: https://lore.kernel.org/r/20240829-arm64-gcs-v12-0-42fec94743 https://lore.kernel.org/lkml/20240403234054.2020347-1-debug@rivosinc.com/ Given the addition of the use of vm_flags in the generic implementation we also simplify the set of possibilities that have to be dealt with in the core code by making arch_get_unmapped_area() take vm_flags as standard. This is a bit invasive since the prototype change touches quite a few architectures but since the parameter is ignored the change is straightforward, the simplification for the generic code seems worth it. This patch (of 3): When we introduced arch_get_unmapped_area_vmflags() in 961148704acd ("mm: introduce arch_get_unmapped_area_vmflags()") we did so as part of properly supporting guard pages for shadow stacks on x86_64, which uses a custom arch_get_unmapped_area(). Equivalent features are also present on both arm64 and RISC-V, both of which use the generic implementation of arch_get_unmapped_area() and will require equivalent modification there. Rather than continue to deal with having two versions of the functions let's bite the bullet and have all implementations of arch_get_unmapped_area() take vm_flags as a parameter. The new parameter is currently ignored by all implementations other than x86. The only caller that doesn't have a vm_flags available is mm_get_unmapped_area(), as for the x86 implementation and the wrapper used on other architectures this is modified to supply no flags. No functional changes. Link: https://lkml.kernel.org/r/20240904-mm-generic-shadow-stack-guard-v2-0-a46b8b6dc0ed@kernel.org Link: https://lkml.kernel.org/r/20240904-mm-generic-shadow-stack-guard-v2-1-a46b8b6dc0ed@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com> Acked-by: Helge Deller <deller@gmx.de> [parisc] Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Andreas Larsson <andreas@gaisler.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Chris Zankel <chris@zankel.net> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David S. Miller <davem@davemloft.net> Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Guo Ren <guoren@kernel.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Matt Turner <mattst88@gmail.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Naveen N Rao <naveen@kernel.org> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Rich Felker <dalias@libc.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Vineet Gupta <vgupta@kernel.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: WANG Xuerui <kernel@xen0n.name> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-09-10RISC-V: configs: enable I2C_DESIGNWARE_CORE with I2C_DESIGNWARE_PLATFORMHeikki Krogerus3-0/+3
The dependency handling of the Synopsys DesignWare I2C adapter drivers is going to be changed so that the glue drivers for the PCI and platform buses depend on I2C_DESIGNWARE_CORE. Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: linux-riscv@lists.infradead.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-09-10mips: configs: enable I2C_DESIGNWARE_CORE with I2C_DESIGNWARE_PLATFORMHeikki Krogerus1-0/+1
The dependency handling of the Synopsys DesignWare I2C adapter drivers is going to be changed so that the glue drivers for the PCI and platform buses depend on I2C_DESIGNWARE_CORE. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: UNGLinuxDriver@microchip.com Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: linux-mips@vger.kernel.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-09-10arm64: defconfig: enable I2C_DESIGNWARE_CORE with I2C_DESIGNWARE_PLATFORMHeikki Krogerus1-0/+1
The dependency handling of the Synopsys DesignWare I2C adapter drivers is going to be changed so that the glue drivers for the PCI and platform buses depend on I2C_DESIGNWARE_CORE. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-09-10ARM: configs: enable I2C_DESIGNWARE_CORE with I2C_DESIGNWARE_PLATFORMHeikki Krogerus7-0/+7
The dependency handling of the Synopsys DesignWare I2C adapter drivers is going to be changed so that the glue drivers for the PCI and platform buses depend on I2C_DESIGNWARE_CORE. Cc: Russell King <linux@armlinux.org.uk> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-09-10ARC: configs: enable I2C_DESIGNWARE_CORE with I2C_DESIGNWARE_PLATFORMHeikki Krogerus4-0/+4
The dependency handling of the Synopsys DesignWare I2C adapter drivers is going to be changed so that the glue drivers for the PCI and platform buses depend on I2C_DESIGNWARE_CORE. Cc: Vineet Gupta <vgupta@kernel.org> Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-09-09Merge tag 'hyperv-fixes-signed-20240908' of ↵Linus Torvalds3-8/+19
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull hyperv fixes from Wei Liu: - Add a documentation overview of Confidential Computing VM support (Michael Kelley) - Use lapic timer in a TDX VM without paravisor (Dexuan Cui) - Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides frequency (Michael Kelley) - Fix a kexec crash due to VP assist page corruption (Anirudh Rayabharam) - Python3 compatibility fix for lsvmbus (Anthony Nandaa) - Misc fixes (Rachel Menge, Roman Kisel, zhang jiao, Hongbo Li) * tag 'hyperv-fixes-signed-20240908' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: hv: vmbus: Constify struct kobj_type and struct attribute_group tools: hv: rm .*.cmd when make clean x86/hyperv: fix kexec crash due to VP assist page corruption Drivers: hv: vmbus: Fix the misplaced function description tools: hv: lsvmbus: change shebang to use python3 x86/hyperv: Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides frequency Documentation: hyperv: Add overview of Confidential Computing VM support clocksource: hyper-v: Use lapic timer in a TDX VM without paravisor Drivers: hv: Remove deprecated hv_fcopy declarations
2024-09-09arm64: defconfig: enable mt8365 soundAlexandre Mergnat1-0/+2
Enable the MediaTek MT8365-EVK sound support. The audio feature is handled by the MT8365 SoC and the MT6357 PMIC codec audio. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20240226-audio-i350-v8-3-e80a57d026ce@baylibre.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2024-09-09arm64: dts: mediatek: add audio support for mt8365-evkAlexandre Mergnat1-0/+86
Add the sound node which is linked to the MT8365 SoC AFE and the MT6357 audio codec. Update the file header. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20240226-audio-i350-v8-5-e80a57d026ce@baylibre.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2024-09-09arm64: dts: mediatek: add afe support for mt8365 SoCAlexandre Mergnat1-2/+41
Add audio front end support of MT8365 SoC. Update the file header. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20240226-audio-i350-v8-4-e80a57d026ce@baylibre.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2024-09-09arm64: dts: mediatek: mt8186-corsola: Disable DPI display interfaceChen-Yu Tsai1-1/+2
The DPI display interface feeds the external display pipeline. However the pipeline representation is currently incomplete. Efforts are still under way to come up with a way to represent the "creative" repurposing of the DP bridge chip's internal output mux, which is meant to support USB type-C orientation changes, to output to one of two type-C ports. Until that is finalized, the external display can't be fully described, and thus won't work. Even worse, the half complete graph potentially confuses the OS, breaking the internal display as well. Disable the external display interface across the whole Corsola family until the DP / USB Type-C muxing graph binding is ready. Reported-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Closes: https://lore.kernel.org/linux-mediatek/38a703a9-6efb-456a-a248-1dd3687e526d@gmail.com/ Fixes: 8855d01fb81f ("arm64: dts: mediatek: Add MT8186 Krabby platform based Tentacruel / Tentacool") Cc: <stable@vger.kernel.org> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240821042836.2631815-1-wenst@chromium.org Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2024-09-09arm64: dts: mediatek: mt8186: Add svs nodeRohit Agarwal1-0/+16
Add clock/irq/efuse setting in svs nodes for mt8186 SoC. Signed-off-by: Rohit Agarwal <rohiagar@chromium.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240830084544.2898512-4-rohiagar@chromium.org Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2024-09-09arm64: dts: mediatek: mt8186: Add power domain for DPIRohit Agarwal1-0/+1
Add power domain phandle to the DPI controller in mediatek mt8186 SoC. Signed-off-by: Rohit Agarwal <rohiagar@chromium.org> Link: https://lore.kernel.org/r/20240830084544.2898512-3-rohiagar@chromium.org Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2024-09-09arm64: dts: mediatek: mt8195: Correct clock order for dp_intf*Chen-Yu Tsai1-6/+6
The clocks for dp_intf* device nodes are given in the wrong order, causing the binding validation to fail. Fixes: 6c2503b5856a ("arm64: dts: mt8195: Add dp-intf nodes") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240802070951.1086616-1-wenst@chromium.org Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2024-09-09arm64: dts: mt8183: add dpi node to mt8183Pi-Hsun Shih1-0/+11
Add dpi node to mt8183. Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Signed-off-by: Fabien Parent <fparent@baylibre.com> Signed-off-by: Pin-yen Lin <treapking@chromium.org> Link: https://lore.kernel.org/r/20240819120735.1508789-1-treapking@chromium.org Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2024-09-09riscv: defconfig: Enable pinctrl support for CV18XX Series SoCInochi Amaoto1-0/+4
Enable pinctrl driver for the whole CV18XX series. Signed-off-by: Inochi Amaoto <inochiama@outlook.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2024-09-09parisc: Fix 64-bit userspace syscall pathHelge Deller1-6/+8
Currently the glibc isn't yet ported to 64-bit for hppa, so there is no usable userspace available yet. But it's possible to manually build a static 64-bit binary and run that for testing. One such 64-bit test program is available at http://ftp.parisc-linux.org/src/64bit.tar.gz and it shows various issues with the existing 64-bit syscall path in the kernel. This patch fixes those issues. Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v4.19+
2024-09-09parisc: Convert to generic clockeventsHelge Deller4-159/+108
Convert parisc timer code to generic clockevents framework. Signed-off-by: Helge Deller <deller@gmx.de>
2024-09-09m68k: remove trailing space after \n newlineColin Ian King1-1/+1
There is a extraneous space after a newline in a pr_debug message. Remove it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2024-09-08riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting ↵Xingyu Wu1-0/+6
PLL0 rate to 1.5GHz CPUfreq supports 4 cpu frequency loads on 375/500/750/1500MHz. But now PLL0 rate is 1GHz and the cpu frequency loads become 250/333/500/1000MHz in fact. The PLL0 rate should be default set to 1.5GHz and set the cpu_core rate to 500MHz in safe. Fixes: e2c510d6d630 ("riscv: dts: starfive: Add cpu scaling for JH7110 SoC") Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2024-09-08treewide: Fix wrong singular form of jiffies in commentsAnna-Maria Behnsen3-3/+3
There are several comments all over the place, which uses a wrong singular form of jiffies. Replace 'jiffie' by 'jiffy'. No functional change. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k Link: https://lore.kernel.org/all/20240904-devel-anna-maria-b4-timers-flseep-v1-3-e98760256370@linutronix.de
2024-09-08smp: Mark smp_prepare_boot_cpu() __initBibo Mao3-3/+3
smp_prepare_boot_cpu() is only called during boot, hence mark it as __init. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Link: https://lore.kernel.org/all/20240907082720.452148-1-maobibo@loongson.cn
2024-09-08arm64: dts: allwinner: h5: NanoPi Neo Plus2: Fix regulatorsKryštof Černý1-0/+25
Added the main board 5 V supply regulator, a 2.5 V supply regulator for GMAC PHY IO and correct vin-supply elements. Signed-off-by: Kryštof Černý <cleverline1mc@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Link: https://lore.kernel.org/r/20240905-nanopi-neo-plus2-regfix-v3-1-1895dff59598@gmail.com [wens@csie.org: Make "h5" lowercase to match most commits] Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2024-09-07s390/boot: Move boot_printk() code to own fileHeiko Carstens3-113/+126
Keep the printk code separate from the program check code and move boot_printk() and helper functions to own printk.c file. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-09-07s390/boot: Use boot_printk() instead of sclp_early_printk()Heiko Carstens5-40/+12
Consistently use boot_printk() everywhere instead of sclp_early_printk() at some places. For some places it was required (e.g. als.c), in order to stay in code compiled for the same architecture level, for other places it is not obvious why sclp_early_printk() was used instead of decompressor_printk(). Given that the whole decompressor code is compiled for the same architecture level, there is no requirement left to use different printk functions. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-09-07s390/boot: Rename decompressor_printk() to boot_printk()Heiko Carstens4-41/+37
Rename decompressor_printk() to boot_printk() just to have a shorter function name, which also makes the code more readable. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-09-07s390/boot: Compile all files with the same march flagHeiko Carstens1-14/+5
Only a couple of files of the decompressor are compiled with the minimum architecture level. This is problematic for potential function calls between compile units, especially if a target function is within a compile until compiled for a higher architecture level, since that may lead to an unexpected operation exception. Therefore compile all files of the decompressor for the same (minimum) architecture level. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-09-07s390: Use MARCH_HAS_*_FEATURES definesHeiko Carstens6-19/+26
Replace CONFIG_HAVE_MARCH_*_FEATURES with MARCH_HAS_*_FEATURES everywhere so code gets compiled correctly depending on if the target is the kernel or the decompressor. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-09-07s390: Provide MARCH_HAS_*_FEATURES definesHeiko Carstens1-0/+38
Provide MARCH_HAS_*_FEATURES defines which are supposed to be used everywhere instead of the CONFIG_HAVE_MARCH_*_FEATURES defines. Various header files contain code which depend on the CONFIG_HAVE_MARCH_*_FEATURES defines, allowing for compile time optimizations. If such code is used within the decompressor wrong code may be generated (the compiler may generate instructions which are not available for the minimum architecture level of the decompressor). Therefore provide a new header file with MARCH_HAS_*_FEATURES defines, which are only available if __DECOMPRESSOR is not defined. This way code generation for the kernel image is still optimized depending on CONFIG_HAVE_MARCH_*_FEATURES, while code generated for the decompressor is compiled for the minimum architecture level. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-09-07s390/facility: Disable compile time optimization for decompressor codeHeiko Carstens1-2/+4
Disable compile time optimizations of test_facility() for the decompressor. The decompressor should not contain any optimized code depending on the architecture level set the kernel image is compiled for to avoid unexpected operation exceptions. Add a __DECOMPRESSOR check to test_facility() to enforce that facilities are always checked during runtime for the decompressor. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-09-07s390/boot: Increase minimum architecture to z10Heiko Carstens1-4/+0
The decompressor code is partially compiled with march=z900 so it is possible to print an error message in case a kernel is booted on a machine which misses facilities to execute the kernel. Given that the decompressor code also includes header files from the core kernel this causes problems for inline assemblies and other code where the minimum assumed architecture level is set to z10 in the meantime. If such code is also used in the decompressor (e.g. inline functions) z900 support must be implemented again. In order to avoid this and to keep things simple just raise the minimum architecture level to z10 for the decompressor just like for the kernel. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-09-07s390/als: Remove obsolete commentHeiko Carstens1-8/+0
The bss section of the decompressor is part of the compressed kernel image since commit 980d5f9ab36b ("s390/boot: enable .bss section for compressed kernel"). Remove a now incorrect comment that states that the bss section must not be accessed. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-09-07ARC: update the help message for CONFIG_ARC_BUILTIN_DTB_NAMEMasahiro Yamada1-1/+1
Commit abe11ddea1d7 ("ARC: [plat-arcfpga]: Enabling DeviceTree for Angel4 board") changed the default built-in DTB from "skeleton" to "angel4". Commit fd1557923b2e ("ARC: [plat_arcfpga]->[plat_sim]") changed it from "angel4" to "nsim_700". Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Vineet Gupta <vgupta@kernel.org>
2024-09-06KVM: x86: don't fall through case statements without annotationsLinus Torvalds1-0/+1
clang warns on this because it has an unannotated fall-through between cases: arch/x86/kvm/x86.c:4819:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] and while we could annotate it as a fallthrough, the proper fix is to just add the break for this case, instead of falling through to the default case and the break there. gcc also has that warning, but it looks like gcc only warns for the cases where they fall through to "real code", rather than to just a break. Odd. Fixes: d30d9ee94cc0 ("KVM: x86: Only advertise KVM_CAP_READONLY_MEM when supported by VM") Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Tom Dohrmann <erbse.13@gmx.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-09-06Merge tag 'arm64-fixes' of ↵Linus Torvalds1-1/+3
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Fix the arm64 usage of ftrace_graph_ret_addr() to pass the &state->graph_idx pointer instead of NULL, otherwise this function just returns early" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: stacktrace: fix the usage of ftrace_graph_ret_addr()
2024-09-06Merge tag 'riscv-for-linus-6.11-rc7' of ↵Linus Torvalds8-94/+79
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - A revert for the mmap() change that ties the allocation range to the hint adress, as what we tried to do ended up regressing on other userspace workloads. - A fix to avoid a kernel memory leak when emulating misaligned accesses from userspace. - A Kconfig fix for toolchain vector detection, which now correctly detects vector support on toolchains where the V extension depends on the M extension. - A fix to avoid failing the linear mapping bootmem bounds check on NOMMU systems. - A fix for early alternatives on relocatable kernels. * tag 'riscv-for-linus-6.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Fix RISCV_ALTERNATIVE_EARLY riscv: Do not restrict memory size because of linear mapping on nommu riscv: Fix toolchain vector detection riscv: misaligned: Restrict user access to kernel memory riscv: mm: Do not restrict mmap address based on hint riscv: selftests: Remove mmap hint address checks Revert "RISC-V: mm: Document mmap changes"
2024-09-06Merge tag 'powerpc-6.11-3' of ↵Linus Torvalds6-10/+26
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - Fix a deadlock in the powerpc qspinlock MCS queue logic - Fix the return type of pgd_val() to not truncate 64-bit PTEs on 85xx - Allow the check for dynamic relocations in the VDSO to work correctly - Make mmu_pte_psize static to fix a build error Thanks to Christophe Leroy, Nysal Jan K.A., Nicholas Piggin, Geetika Moolchandani, Jijo Varghese, and Vaishnavi Bhat. * tag 'powerpc-6.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/qspinlock: Fix deadlock in MCS queue powerpc/mm: Fix return type of pgd_val() powerpc/vdso: Don't discard rela sections powerpc/64e: Define mmu_pte_psize static
2024-09-06Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds7-13/+34
Pull x86 kvm fixes from Paolo Bonzini: "Many small fixes that accumulated while I was on vacation... - Fixup missed comments from the REMOVED_SPTE => FROZEN_SPTE rename - Ensure a root is successfully loaded when pre-faulting SPTEs - Grab kvm->srcu when handling KVM_SET_VCPU_EVENTS to guard against accessing memslots if toggling SMM happens to force a VM-Exit - Emulate MSR_{FS,GS}_BASE on SVM even though interception is always disabled, so that KVM does the right thing if KVM's emulator encounters {RD,WR}MSR - Explicitly clear BUS_LOCK_DETECT from KVM's caps on AMD, as KVM doesn't yet virtualize BUS_LOCK_DETECT on AMD - Cleanup the help message for CONFIG_KVM_AMD_SEV, and call out that KVM now supports SEV-SNP too - Specialize return value of KVM_CHECK_EXTENSION(KVM_CAP_READONLY_MEM), based on VM type - Remove unnecessary dependency on CONFIG_HIGH_RES_TIMERS - Note an RCU quiescent state on guest exit. This avoids a call to rcu_core() if there was a grace period request while guest was running" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: Remove HIGH_RES_TIMERS dependency kvm: Note an RCU quiescent state on guest exit KVM: x86: Only advertise KVM_CAP_READONLY_MEM when supported by VM KVM: SEV: Update KVM_AMD_SEV Kconfig entry and mention SEV-SNP KVM: SVM: Don't advertise Bus Lock Detect to guest if SVM support is missing KVM: SVM: fix emulation of msr reads/writes of MSR_FS_BASE and MSR_GS_BASE KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS KVM: x86/mmu: Check that root is valid/loaded when pre-faulting SPTEs KVM: x86/mmu: Fixup comments missed by the REMOVED_SPTE=>FROZEN_SPTE rename
2024-09-06arm64/mm: use lm_alias() with addresses passed to memblock_free()Joey Gouly1-5/+7
The pointer argument to memblock_free() needs to be a linear map address, but in mem_init() we pass __init_begin/__init_end, which is a kernel image address. This results in warnings when building with CONFIG_DEBUG_VIRTUAL=y: virt_to_phys used for non-linear address: ffff800081270000 (set_reset_devices+0x0/0x10) WARNING: CPU: 0 PID: 1 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x54/0x70 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240905 #5810 b1ebb0ad06653f35ce875413d5afad24668df3f3 Hardware name: FVP Base RevC (DT) pstate: 2161402005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __virt_to_phys+0x54/0x70 lr : __virt_to_phys+0x54/0x70 sp : ffff80008169be20 ... Call trace: __virt_to_phys+0x54/0x70 memblock_free+0x18/0x30 free_initmem+0x3c/0x9c kernel_init+0x30/0x1cc ret_from_fork+0x10/0x20 Fix this by having mem_init() convert the pointers via lm_alias(). Fixes: 1db9716d4487 ("arm64/mm: Delete __init region from memblock.reserved") Signed-off-by: Joey Gouly <joey.gouly@arm.com> Suggested-by: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Rong Qianfeng <rongqianfeng@vivo.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20240905152935.4156469-1-joey.gouly@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2024-09-06mm: arm64: document why pte is not advanced in contpte_ptep_set_access_flags()Barry Song1-0/+6
According to David and Ryan, there isn't a bug here, even though we don't advance the PTE entry, because __ptep_set_access_flags() only uses the access flags from the entry. However, we always check pte_same(pte, entry) using the first entry in __ptep_set_access_flags(). This means that the checks from 1 to nr - 1 are not comparing the same PTE indexes (thus, they always return false), which can be a bit confusing. To clarify the code, let's add some comments. Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Barry Song <v-songbaohua@oppo.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: David Hildenbrand <david@redhat.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20240905081124.9576-1-21cnbao@gmail.com Signed-off-by: Will Deacon <will@kernel.org>
2024-09-06crypto: x86/aesni - update docs for aesni-intel moduleEric Biggers2-3/+7
Update the kconfig help and module description to reflect that VAES instructions are now used in some cases. Also fix XTR => XCTR. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-09-05ARM: spitz: Use software nodes/properties for the matrix keypadDmitry Torokhov1-23/+41
Convert the Spitz to use software nodes and static properties to describe GPIOs and other parameters of its matrix keypad. Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240805014710.1961677-5-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2024-09-05ARM: spitz: Use software nodes/properties for the GPIO-driven buttonsDmitry Torokhov1-31/+68
Convert the Spitz to use software nodes and static properties to describe GPIOs for the GPIO-driven buttons. Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240805014710.1961677-4-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2024-09-05x86/sgx: Log information when a node lacks an EPC sectionAaron Lu1-0/+7
For optimized performance, firmware typically distributes EPC sections evenly across different NUMA nodes. However, there are scenarios where a node may have both CPUs and memory but no EPC section configured. For example, in an 8-socket system with a Sub-Numa-Cluster=2 setup, there are a total of 16 nodes. Given that the maximum number of supported EPC sections is 8, it is simply not feasible to assign one EPC section to each node. This configuration is not incorrect - SGX will still operate correctly; it is just not optimized from a NUMA standpoint. For this reason, log a message when a node with both CPUs and memory lacks an EPC section. This will provide users with a hint as to why they might be experiencing less-than-ideal performance when running SGX enclaves. Suggested-by: Dave Hansen <dave.hansen@intel.com> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Acked-by: Kai Huang <kai.huang@intel.com> Link: https://lore.kernel.org/all/20240905080855.1699814-3-aaron.lu%40intel.com
2024-09-05x86/sgx: Fix deadlock in SGX NUMA node searchAaron Lu1-13/+14
When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will. Fixes: 901ddbb9ecf5 ("x86/sgx: Add a basic NUMA allocation scheme to sgx_alloc_epc_page()") Reported-by: "Molina Sabido, Gerardo" <gerardo.molina.sabido@intel.com> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Tested-by: Zhimin Luo <zhimin.luo@intel.com> Link: https://lore.kernel.org/all/20240905080855.1699814-2-aaron.lu%40intel.com
2024-09-05arm64: dts: rockchip: add CAN0 and CAN1 interfaces to mecsbc boardDavid Jander1-0/+14
This patch adds support for the CAN0 and CAN1 interfaces to the board. Signed-off-by: David Jander <david@protonic.nl> Tested-by: Alibek Omarov <a1ba.omarov@gmail.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20240904-rk3568-canfd-v1-2-73bda5fb4e03@pengutronix.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-09-05arm64: dts: rockchip: add CAN-FD controller nodes to rk3568David Jander1-0/+39
Add nodes to the rk3568 devicetree to support the CAN-FD controllers. Signed-off-by: David Jander <david@protonic.nl> Tested-by: Alibek Omarov <a1ba.omarov@gmail.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20240904-rk3568-canfd-v1-1-73bda5fb4e03@pengutronix.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>