summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2025-10-22powerpc: cell: make spu_subsys constAdrian Barnaś1-1/+1
Because driver core can properly handle constant struct bus_type, move the spu_subsys to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Signed-off-by: Adrian Barnaś <abarnas@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20250918141633.339803-1-abarnas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-22arm: make sa1111_bus_type constAdrian Barnaś2-2/+2
Because driver core can properly handle constant struct bus_type, move the sa1111_bus_type to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Signed-off-by: Adrian Barnaś <abarnas@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20250918134429.270814-1-abarnas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-22bpf: Do not audit capability check in do_jit()Ondrej Mosnacek1-1/+1
The failure of this check only results in a security mitigation being applied, slightly affecting performance of the compiled BPF program. It doesn't result in a failed syscall, an thus auditing a failed LSM permission check for it is unwanted. For example with SELinux, it causes a denial to be reported for confined processes running as root, which tends to be flagged as a problem to be fixed in the policy. Yet dontauditing or allowing CAP_SYS_ADMIN to the domain may not be desirable, as it would allow/silence also other checks - either going against the principle of least privilege or making debugging potentially harder. Fix it by changing it from capable() to ns_capable_noaudit(), which instructs the LSMs to not audit the resulting denials. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2369326 Fixes: d4e89d212d40 ("x86/bpf: Call branch history clearing sequence on exit") Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Reviewed-by: Paul Moore <paul@paul-moore.com> Link: https://lore.kernel.org/r/20251021122758.2659513-1-omosnace@redhat.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-10-22csky: abiv2: adapt to new folio flags fieldThomas Weißschuh2-3/+3
Recent changes require the raw folio flags to be accessed via ".f". The merge commit introducing this change adapted most architecture code but forgot the csky abiv2. [rppt@kernel.org: add fix for arch/csky/abiv2/cacheflush.c] Link: https://lkml.kernel.org/r/aPCE238oxAB9QcZa@kernel.org Fixes: 53fbef56e07d ("mm: introduce memdesc_flags_t") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: Guo Ren <guoren@kernel.org> Acked-by: Zi Yan <ziy@nvidia.com> Cc: Guo Ren <guoren@kernel.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-10-21arm64: dts: exynos: gs101: fix sysreg_apm reg propertyPeter Griffin1-2/+2
Both the start address and size are incorrect for the apm_sysreg DT node. Update to match the TRM (rather than how it was defined downstream). Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: André Draszik <andre.draszik@linaro.org> Link: https://patch.msgid.link/20251013-automatic-clocks-v1-5-72851ee00300@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-10-21arm64: dts: exynos: gs101: fix clock module unit reg sizesPeter Griffin1-7/+7
The memory map lists each clock module unit as having a size of 0x10000. Additionally there are some undocumented registers in this region that need to be used for automatic clock gating mode. Some of those registers also need to be saved/restored on suspend & resume. Fixes: 86124c76683e ("arm64: dts: exynos: gs101: enable cmu-hsi2 clock controller") Fixes: 4982a4a2092e ("arm64: dts: exynos: gs101: enable cmu-hsi0 clock controller") Fixes: 7d66d98b5bf3 ("arm64: dts: exynos: gs101: enable cmu-peric1 clock controller") Fixes: e62c706f3aa0 ("arm64: dts: exynos: gs101: enable cmu-peric0 clock controller") Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: André Draszik <andre.draszik@linaro.org> Link: https://patch.msgid.link/20251013-automatic-clocks-v1-4-72851ee00300@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-10-21arm64: dts: exynos: gs101: add sysreg_misc and sysreg_hsi0 nodesPeter Griffin1-0/+12
Add syscon DT node for the hsi0 and misc sysreg controllers. These will be referenced by their respective CMU nodes in future patches. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: André Draszik <andre.draszik@linaro.org> Link: https://patch.msgid.link/20251013-automatic-clocks-v1-3-72851ee00300@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-10-21arm64, mm: avoid always making PTE dirty in pte_mkwrite()Huang Ying1-1/+2
Current pte_mkwrite_novma() makes PTE dirty unconditionally. This may mark some pages that are never written dirty wrongly. For example, do_swap_page() may map the exclusive pages with writable and clean PTEs if the VMA is writable and the page fault is for read access. However, current pte_mkwrite_novma() implementation always dirties the PTE. This may cause unnecessary disk writing if the pages are never written before being reclaimed. So, change pte_mkwrite_novma() to clear the PTE_RDONLY bit only if the PTE_DIRTY bit is set to make it possible to make the PTE writable and clean. The current behavior was introduced in commit 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()"). Before that, pte_mkwrite() only sets the PTE_WRITE bit, while set_pte_at() only clears the PTE_RDONLY bit if both the PTE_WRITE and the PTE_DIRTY bits are set. To test the performance impact of the patch, on an arm64 server machine, run 16 redis-server processes on socket 1 and 16 memtier_benchmark processes on socket 0 with mostly get transactions (that is, redis-server will mostly read memory only). The memory footprint of redis-server is larger than the available memory, so swap out/in will be triggered. Test results show that the patch can avoid most swapping out because the pages are mostly clean. And the benchmark throughput improves ~23.9% in the test. Fixes: 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()") Signed-off-by: Huang Ying <ying.huang@linux.alibaba.com> Cc: Will Deacon <will@kernel.org> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Gavin Shan <gshan@redhat.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Yicong Yang <yangyicong@hisilicon.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-10-21x86/bugs: Qualify RETBLEED_INTEL_MSGDavid Kaplan1-1/+3
When retbleed mitigation is disabled, the kernel already prints an info message that the system is vulnerable. Recent code restructuring also inadvertently led to RETBLEED_INTEL_MSG being printed as an error, which is unnecessary as retbleed mitigation was already explicitly disabled (by config option, cmdline, etc.). Qualify this print statement so the warning is not printed unless an actual retbleed mitigation was selected and is being disabled due to incompatibility with spectre_v2. Fixes: e3b78a7ad5ea ("x86/bugs: Restructure retbleed mitigation") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220624 Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251003171936.155391-1-david.kaplan@amd.com
2025-10-21x86/microcode: Fix Entrysign revision check for Zen1/NaplesAndrew Cooper1-1/+1
... to match AMD's statement here: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html Fixes: 50cef76d5cb0 ("x86/microcode/AMD: Load only SHA256-checksummed patches") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: <stable@kernel.org> Link: https://patch.msgid.link/20251020144124.2930784-1-andrew.cooper3@citrix.com
2025-10-21s390/ap: Introduce new AP nqap and dqap trace eventsHarald Freudenberger1-0/+87
Introduce two new AP bus related tracepoint events: - There is a tracepoint s390_ap_nqap event immediately after a request has been pushed into the AP firmware queue with the NQAP AP command. - The other tracepoint s390_ap_dqap event fires immediately after a reply has been pulled out of the AP firmware queue via DQAP AP command. Both events are triggered unconditional and may need filtering. Filtering can be done based on the status value which is part of the nqap and dqap trace. So for example a echo "!(status & 0x00ff0000)" >.../s390_ap_dqap/filter filters out all trace events which have a response_code != 0 leaving just the successful nqap and dqap invocations. The idea of these two trace events focuses on performance to measure the runtime of a crypto request/reply as close as possible at the firmware level. In combination with the two zcrypt tracepoints (see the zcrypt.h trace event definition file) this gives measurement data about the runtime of a request/reply within the zcrpyt and AP bus layer. However, with having the status of these AP commands in hand also other usage may be possible. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21s390/ap: Extend struct ap_queue_status with some convenience fieldsHarald Freudenberger1-8/+22
Sometimes there is a different view of the AP status word needed. So here is slight rework of the struct ap_queue_status to open up the possibility to have different ways of accessing the AP status bits and fields. The new struct ap_queue_status struct ap_queue_status { union { unsigned int value : 32; struct { unsigned int status_bits : 8; unsigned int rc : 8; unsigned int : 16; }; struct { unsigned int queue_empty : 1; unsigned int replies_waiting : 1; unsigned int queue_full : 1; unsigned int : 3; unsigned int async : 1; unsigned int irq_enabled : 1; unsigned int response_code : 8; unsigned int : 16; }; }; }; comprises the old struct ap_queue_status but extends it to have this also accessible as an unsigned int required for example for a simple print or trace of the whole value. Note that this rework is fully backward compatible to the existing code exploiting the struct ap_queue_status. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21s390/zcrypt: Rework zcrypt request and reply trace event definitionHarald Freudenberger1-20/+24
This is a slight rework of the s390_zcrypt_req and s390_zcrypt_rep trace event: - the psmid has been added to the s390_zcrypt_rep - "dev" renamed to "card" - "domain" renamed to "dom" The motivation of these changes is to make these traces more aligned to new upcoming traces for AP bus related trace events. Additionally the psmid is needed to match the reply (and thus indirect the request) to AP bus related trace events where only the psmid is unique identifying AP messages. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21arm64: dts: imx: correct the flexspi compatible string to match with yamlHaibo Chen2-2/+2
According to Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml, imx93/imx95 should use it's own compatible string and fallback compatible with imx8mm. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-21arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fanJoy Zou1-0/+1
Add fan-supply regulator to pwm-fan node to specify power source. Fixes: e3e8b199aff8 ("arm64: dts: imx95: Add imx95-15x15-evk support") Signed-off-by: Joy Zou <joy.zou@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-21s390/ptdump: Use seq_puts() in pt_dump_seq_puts() macroJosephine Pfeiffer1-1/+1
The pt_dump_seq_puts() macro incorrectly uses seq_printf() instead of seq_puts(). This is both a performance issue and conceptually wrong, as the macro name suggests plain string output (puts) but the implementation uses formatted output (printf). The macro is used in dump_pagetables.c:67-68 and 131 to output constant strings. Using seq_printf() adds unnecessary overhead for format string parsing. Signed-off-by: Josephine Pfeiffer <hi@josie.lol> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1Tim Harvey2-31/+0
SDHC1 on the GW702x SOM routes to a connector for use on a baseboard and as such are defined in the baseboard device-trees. Remove it from the gw702x SOM device-tree. Fixes: 0d5b288c2110 ("arm64: dts: freescale: Add imx8mp-venice-gw7905-2x") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-21arm64: dts: imx8mp-venice-gw702x: remove off-board uartTim Harvey1-28/+0
UART1 and UART3 go to a connector for use on a baseboard and as such are defined in the baseboard device-trees. Remove them from the gw702x SOM device-tree. Fixes: 0d5b288c2110 ("arm64: dts: freescale: Add imx8mp-venice-gw7905-2x") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-21arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrlTim Harvey1-11/+0
The SDHC1 interface is not used on the imx8mm-venice-gw72xx. Remove the unused pinctrl_usdhc1 iomux node. Fixes: 6f30b27c5ef5 ("arm64: dts: imx8mm: Add Gateworks i.MX 8M Mini Development Kits") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-21arm64: dts: imx8mm-venice-gw700x: reduce RGMII CLK drive strengthTim Harvey1-1/+1
The i.MX8M Mini FEC RGMII tracelength is less than 1in and does not require a x6 drive strength. Reduce the CLK drive strength to x1 for lower emissions. Additionally since TXC is not a high frequency clock, use slow slew rate (FSEL=0) for lower emmissions and improved signal quality. Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-21arm64: dts: imx8mp-venice-gw702x: reduce RGMII CLK drive strengthTim Harvey1-1/+1
The i.MX8M Plus EQOS RGMII tracelength is less than 1in and does not require a x6 drive strength. Reduce the CLK drive strength to x1 for lower emissions. Additionally since TXC is not a high frequency clock, use slow slew rate (FSEL=0) for lower emmissions and improved signal quality. Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-21arm64: dts: imx8m{m,n,p}-venice: disable unused clk output for TI PHYTim Harvey5-0/+5
Disable the unused refclk output for the TI DP83867 PHY used on Gateworks Venice boards. Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-21arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1 propsTim Harvey1-3/+0
Remove the un-intended duplicate properties from usdhc1. Fixes: 0d5b288c2110e ("arm64: dts: freescale: Add imx8mp-venice-gw7905-2x") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-21Merge branch 'tape-block-sizes'Heiko Carstens2-0/+78
Jan Höppner says: ==================== The tape device driver is limited to a block size of 65535 bytes since a single CCW can only transfer up to 64K-1 bytes (The count field is a 16bit value). This series introduces data chaining for all read/write functions to support block sizes larger than 65535. The tape device type 3490 (emulated) and 3590/3592 can handle up to 256K. [1] [1] https://www.ibm.com/docs/en/zos/3.1.0?topic=blksize-system-determined-block-size ==================== Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21s390/tape: Introduce idal buffer arrayJan Höppner2-0/+78
The tape device driver uses a single idal_buffer for I/O. While the buffer itself can be arbitrary big, the limit for data transfer for a single Channel-Command Word is at 65535 bytes (64K-1) since the count field specifying the amount of data designated by the CCW is a 16-bit unsigned value. Provide functionality that allocates an array of multiple IDAL buffer with the limitation mentioned above in mind. A call to idal_buffer_array_alloc() allocates an array with a certain amount of IDAL buffers which is determined based on the total size of @size. Each individual buffer is limited to a size of CCW_MAX_BYTE_COUNT (65535 bytes). Add helper functions that determine the size (# of elements) and the total data size covered by the array as well. Current users of the single IDAL buffer are adapted to use the new functions with one buffer to allocate. The single IDAL buffer is removed from the tape_char_data struct. Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Reviewed-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21Merge branch 'memory-hotplug'Heiko Carstens2-9/+14
Sumanth Korikkar says: ==================== Provide a new interface for dynamic configuration and deconfiguration of hotplug memory on s390, allowing with/without memmap_on_memory support. It is a follow up on the discussion with David when introducing memmap_on_memory support for s390 and support dynamic (de)configuration of memory: https://lore.kernel.org/all/ee492da8-74b4-4a97-8b24-73e07257f01d@redhat.com/ https://lore.kernel.org/all/20241202082732.3959803-1-sumanthk@linux.ibm.com/ The original motivation for introducing memmap_on_memory on s390 was to avoid using online memory to store struct pages metadata, particularly for standby memory blocks. This became critical in cases where there was an imbalance between standby and online memory, potentially leading to boot failures due to insufficient memory for metadata allocation. To address this, memmap_on_memory was utilized on s390. However, in its current form, it adds struct pages metadata at the start of each memory block at the time of addition (only standby memory), and this configuration is static. It cannot be changed at runtime (When the user needs continuous physical memory). Inorder to provide more flexibility to the user and overcome the above limitation, add an option to dynamically configure and deconfigure hotpluggable memory block with/without memmap_on_memory. With the new interface, s390 will not add all possible hotplug memory in advance, like before, to make it visible in sysfs for online/offline actions. Instead, before memory block can be set online, it has to be configured via a new interface in /sys/firmware/memory/memoryX/config, which makes s390 similar to others. i.e. Adding of hotpluggable memory is controlled by the user instead of adding it at boottime. s390 kernel sysfs interface to configure/deconfigure memory with memmap_on_memory (with upcoming lsmem changes): * Initial memory layout: lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x7fffffff 2G online 0-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes * Configure memory echo 1 > /sys/firmware/memory/memory16/config lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x7fffffff 2G online 0-15 yes no 0x80000000-0x87ffffff 128M offline 16 yes yes 0x88000000-0xffffffff 1.9G offline 17-31 no yes * Deconfigure memory echo 0 > /sys/firmware/memory/memory16/config lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x7fffffff 2G online 0-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes * Enable memmap_on_memory and online it. (Deconfigure first) echo 0 > /sys/devices/system/memory/memory5/online echo 0 > /sys/firmware/memory/memory5/config lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x27ffffff 640M online 0-4 yes no 0x28000000-0x2fffffff 128M offline 5 no no 0x30000000-0x7fffffff 1.3G online 6-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes (Enable memmap_on_memory and online it) echo 1 > /sys/firmware/memory/memory5/memmap_on_memory echo 1 > /sys/firmware/memory/memory5/config echo 1 > /sys/devices/system/memory/memory5/online lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x27ffffff 640M online 0-4 yes no 0x28000000-0x2fffffff 128M online 5 yes yes 0x30000000-0x7fffffff 1.3G online 6-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes * Disable memmap_on_memory and online it. (Deconfigure first) echo 0 > /sys/devices/system/memory/memory5/online echo 0 > /sys/firmware/memory/memory5/config lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x27ffffff 640M online 0-4 yes no 0x28000000-0x2fffffff 128M offline 5 no yes 0x30000000-0x7fffffff 1.3G online 6-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes (Disable memmap_on_memory and online it) echo 0 > /sys/firmware/memory/memory5/memmap_on_memory echo 1 > /sys/firmware/memory/memory5/config echo 1 > /sys/devices/system/memory/memory5/online lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x7fffffff 2G online 0-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes * Userspace changes: lsmem/chmem tool is also changed to use the new interface. I will send it to util-linux soon. Patch 1 adds support for removal of boot-allocated memory blocks. Patch 2 provides option to dynamically configure and deconfigure memory with/without memmap_on_memory. Patch 3 removes MHP_OFFLINE_INACCESSIBLE from s390. The mhp flag was used to mark memory as not accessible until memory hotplug online phase begins. However, with patch 2, it is no longer essential. Memory can be brought to accessible state before adding memory, as the memory is added during runttime now instead of boottime. Patch 4 removes the MEM_PREPARE_ONLINE/MEM_FINISH_OFFLINE notifiers. It is no longer needed. Memory can be brought to accessible state before adding memory now, with runtime (de)configuration of memory. Note: The patches apply to the linux-next branch. v3: Thanks David * Avoid goto label in create_standby_sclp_mems(). * Use unsigned long instead of u64. * Add Acked-by. v2: Thanks David * Rename struct mblock/mblock_arg with struct sclp_mem/sclp_mem_arg. * Rename all mblocks/mblock references with sclp_mems/sclp_mem - structures, functions. * Rename create_online_mblock() with create_configured_sclp_mem(). * Rename config_mblock_show()/config_mblock_store() with config_sclp_mem_show()/config_sclp_mem_store(). * Remove contains_standby_increment() and sclp_mem_notifier. sclp mem state change is performed when adding/removing memory. sclp memory notifier - no longer needed with this patchset. * Recover sclp mem state when add_memory() fails. * Refactor and add function init_sclp_mem(). * Use unsigned long instead of unsigned long long. * Simplify and correct kobj handling. Thanks Heiko. ==================== Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21s390/early: Use scnprintf() instead of sprintf()Heiko Carstens1-9/+9
Use scnprintf() instead of sprintf() for those cases where the destination is an array and the size of the array is known at compile time. This prevents theoretical buffer overflows, but also avoids that people again and again spend time to figure out if the code is actually safe. Reviewed-by: Jan Polensky <japo@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21s390/pai_crypto: Adjust paicrypt_copy() return statementThomas Richter1-1/+1
Adjust the return statement in paicrypt_copy() to the same statement as in paiext_copy(). Use one common style. No functional change. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Jan Polensky <japo@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21s390/sysinfo: Replace sprintf() with snprintf() for buffer safetyJosephine Pfeiffer1-1/+1
Replace sprintf() with snprintf() when formatting symlink target name to prevent potential buffer overflow. The link_to buffer is only 10 bytes, and using snprintf() ensures proper bounds checking if the topology nesting limit value is unexpectedly large. Signed-off-by: Josephine Pfeiffer <hi@josie.lol> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21s390/extmem: Replace sprintf() with snprintf() for buffer safetyJosephine Pfeiffer1-6/+8
Replace unsafe sprintf() calls with snprintf() in segment_save() to prevent potential buffer overflows. The function builds command strings by repeatedly appending to a fixed-size buffer, which could overflow if segment ranges are numerous or values are large. Signed-off-by: Josephine Pfeiffer <hi@josie.lol> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21s390/cmm: Replace sprintf() with scnprintf() for buffer safetyJosephine Pfeiffer1-2/+2
Replace sprintf() with scnprintf() in cmm_timeout_handler() to prevent potential buffer overflow. The scnprintf() function ensures we don't write beyond the buffer size and provides safer string formatting. Signed-off-by: Josephine Pfeiffer <hi@josie.lol> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-21arm64: dts: ten64: add board controller bindingMathew McBride1-0/+4
The board (micro)controller[1] is responsible for functions such as power supply sequencing, SoC reset as well as serial/MAC address storage, bootcount and scratch registers. There is currently no Linux kernel driver for this controller, however, there is a driver in U-Boot which utilises this binding. [1] https://ten64doc.traverse.com.au/hardware/microcontroller/ Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-21arm64: dts: rockchip: Fix indentation on rk3399 haikou demo dtsoHeiko Stuebner1-5/+5
The regulator-cam-dovdd-1v8 uses spaces for indentation, where it should use tabs. Fix this. Fixes: 066a69db9db3 ("arm64: dts: rockchip: add overlay for RK3399 Puma Haikou Video Demo adapter") Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://patch.msgid.link/20251020091139.3652738-1-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-21x86/ioapic: Simplify mp_irqdomain_alloc() slightlyChristophe JAILLET1-1/+1
The IRQ return value of irq_find_mapping() is only tested for existence, not used for anything else. So, this call can be replaced by a slightly simpler irq_resolve_mapping() call, which reduces generated code size a bit (x86-64 allmodconfig): text data bss dec hex filename 82142 38633 18048 138823 21e47 arch/x86/kernel/apic/io_apic.o.before 81932 38633 18048 138613 21d75 arch/x86/kernel/apic/io_apic.o.after [ mingo: Fixed & simplified the changelog ] Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: kernel-janitors@vger.kernel.org Link: https://patch.msgid.link/cb3a4968538637aac3a5ae4f5ecc4f5eb43376ea.1760861877.git.christophe.jaillet@wanadoo.fr
2025-10-20dts: starfive: jh7110-common: split out mmc0 reset pins from common into boardsE Shattow6-11/+65
Prepare for Orange Pi RV using jh7110-common.dtsi having GPIO62 assignment different than mmc0 reset by splitting this out into each board dts. Signed-off-by: E Shattow <e@freeshell.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-10-20KVM: VMX: Inject #UD if guest tries to execute SEAMCALL or TDCALLSean Christopherson3-0/+17
Add VMX exit handlers for SEAMCALL and TDCALL to inject a #UD if a non-TD guest attempts to execute SEAMCALL or TDCALL. Neither SEAMCALL nor TDCALL is gated by any software enablement other than VMXON, and so will generate a VM-Exit instead of e.g. a native #UD when executed from the guest kernel. Note! No unprivileged DoS of the L1 kernel is possible as TDCALL and SEAMCALL #GP at CPL > 0, and the CPL check is performed prior to the VMX non-root (VM-Exit) check, i.e. userspace can't crash the VM. And for a nested guest, KVM forwards unknown exits to L1, i.e. an L2 kernel can crash itself, but not L1. Note #2! The Intel® Trust Domain CPU Architectural Extensions spec's pseudocode shows the CPL > 0 check for SEAMCALL coming _after_ the VM-Exit, but that appears to be a documentation bug (likely because the CPL > 0 check was incorrectly bundled with other lower-priority #GP checks). Testing on SPR and EMR shows that the CPL > 0 check is performed before the VMX non-root check, i.e. SEAMCALL #GPs when executed in usermode. Note #3! The aforementioned Trust Domain spec uses confusing pseudocode that says that SEAMCALL will #UD if executed "inSEAM", but "inSEAM" specifically means in SEAM Root Mode, i.e. in the TDX-Module. The long- form description explicitly states that SEAMCALL generates an exit when executed in "SEAM VMX non-root operation". But that's a moot point as the TDX-Module injects #UD if the guest attempts to execute SEAMCALL, as documented in the "Unconditionally Blocked Instructions" section of the TDX-Module base specification. Cc: stable@vger.kernel.org Cc: Kai Huang <kai.huang@intel.com> Cc: Xiaoyao Li <xiaoyao.li@intel.com> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20251016182148.69085-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-10-20ARM: dts: socfpga: add Enclustra SoM dts filesLothar Rubusch25-0/+408
Add the approach to set up a combination of Enclustra's SoM on a carrier board and corresponding boot-mode as single device-tree target. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-10-20ARM: dts: socfpga: removal of generic PE1 dtsLothar Rubusch2-56/+0
Remove the older socfpga_arria10_mercury_pe1.dts, since it is duplicate, the hardware is covered by the combination of Enclustra's .dtsi files. The older .dts was limited to only the case of having an Enclustra Mercury+ AA1 on a Mercury+ PE1 base board, booting from sdmmc. This functionality is provided also by the generic Enclustra dtsi and dts files, in particular socfpga_arria10_mercury_aa1_pe1_sdmmc.dts. Since both .dts files cover the same, the older one is to e replaced in favor of the more modularized approach. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Acked-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-10-20ARM: dts: socfpga: add Mercury AA1 variantsLothar Rubusch1-22/+121
Introduce support for Enclustra's Mercury+ AA1 SoM, based on Intel Arria10. This is a flexible approach to allow for combining SoM with carrier board .dtsi and boot-mode .dtsi in a device-tree file. Signed-off-by: Andreas Buerkler <andreas.buerkler@enclustra.com> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-10-20ARM: dts: socfpga: add Enclustra Mercury+ SA2Lothar Rubusch1-0/+146
Introduce Enclustra's Mercury+ SA2 SoM based on Intel Cyclone5 technology as a .dtsi file. Signed-off-by: Andreas Buerkler <andreas.buerkler@enclustra.com> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-10-20ARM: dts: socfpga: add Enclustra Mercury SA1Lothar Rubusch1-0/+143
Introduce support for Enclustra's Mercury SA1 SoM based on Intel Cyclone5 technology as a .dtsi file. Signed-off-by: Andreas Buerkler <andreas.buerkler@enclustra.com> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-10-20ARM: dts: socfpga: add Enclustra base-board dtsiLothar Rubusch3-0/+103
Add generic Enclustra base-board support for the Mercury+ PE1, the Mercury+ PE3 and the Mercury+ ST1 board. The carrier boards can be freely combined with the SoMs Mercury+ AA1, Mercury SA1 and Mercury+ SA2. Signed-off-by: Andreas Buerkler <andreas.buerkler@enclustra.com> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-10-20ARM: dts: socfpga: add Enclustra boot-mode dtsiLothar Rubusch3-0/+28
Add generic boot-mode support to Enclustra Arria10 and Cyclone5 boards. Some Enclustra carrier boards need hardware adjustments specific to the selected boot-mode. Enclustra's Arria10 SoMs allow for booting from different media. By muxing certain IO pins, the media can be selected. This muxing can be done by gpios at runtime e.g. when flashing QSPI from off the bootloader. But also to have statically certain boot media available, certain adjustments to the DT are needed: - SD: QSPI must be disabled - eMMC: QSPI must be disabled, bus width can be doubled to 8 byte - QSPI: any mmc is disabled, QSPI then defaults to be enabled The boot media must be accessible to the bootloader, e.g. to load a bitstream file, but also to the system to mount the rootfs and to use the specific performance. Signed-off-by: Andreas Buerkler <andreas.buerkler@enclustra.com> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-10-20x86,fs/resctrl: Fix NULL pointer dereference with events force-disabled in ↵Babu Moger1-1/+10
mbm_event mode The following NULL pointer dereference is encountered on mount of resctrl fs after booting a system that supports assignable counters with the "rdt=!mbmtotal,!mbmlocal" kernel parameters: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:mbm_cntr_get Call Trace: rdtgroup_assign_cntr_event rdtgroup_assign_cntrs rdt_get_tree Specifying the kernel parameter "rdt=!mbmtotal,!mbmlocal" effectively disables the legacy X86_FEATURE_CQM_MBM_TOTAL and X86_FEATURE_CQM_MBM_LOCAL features and the MBM events they represent. This results in the per-domain MBM event related data structures to not be allocated during early initialization. resctrl fs initialization follows by implicitly enabling both MBM total and local events on a system that supports assignable counters (mbm_event mode), but this enabling occurs after the per-domain data structures have been created. After booting, resctrl fs assumes that an enabled event can access all its state. This results in NULL pointer dereference when resctrl attempts to access the un-allocated structures of an enabled event. Remove the late MBM event enabling from resctrl fs. This leaves a problem where the X86_FEATURE_CQM_MBM_TOTAL and X86_FEATURE_CQM_MBM_LOCAL features may be disabled while assignable counter (mbm_event) mode is enabled without any events to support. Switching between the "default" and "mbm_event" mode without any events is not practical. Create a dependency between the X86_FEATURE_{CQM_MBM_TOTAL,CQM_MBM_LOCAL} and X86_FEATURE_ABMC (assignable counter) hardware features. An x86 system that supports assignable counters now requires support of X86_FEATURE_CQM_MBM_TOTAL or X86_FEATURE_CQM_MBM_LOCAL. This ensures all needed MBM related data structures are created before use and that it is only possible to switch between "default" and "mbm_event" mode when the same events are available in both modes. This dependency does not exist in the hardware but this usage of these feature settings work for known systems. [ bp: Massage commit message. ] Fixes: 13390861b426e ("x86,fs/resctrl: Detect Assignable Bandwidth Monitoring feature details") Co-developed-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Babu Moger <babu.moger@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://patch.msgid.link/a62e6ac063d0693475615edd213d5be5e55443e6.1760560934.git.babu.moger@amd.com
2025-10-20arm64: dts: socfpga: agilex5: Add SMMU nodesKhairul Anuar Romli1-0/+16
Agilex5 includes an ARM SMMU v3 (System Memory Management Unit) to provide address translation and memory protection for DMA-capable devices such as PCIe, USB, and other peripherals. This commit adds the SMMU node to the Agilex5 device tree with compatible string "arm,smmu-v3", along with its register space and interrupts. The SMMU is required to: - Enable DMA address translation for devices that cannot directly access the full physical memory space. - Provide isolation and memory protection by restricting device access to specific regions of memory, improving system security. - Support virtualization use cases by enabling safe and isolated device passthrough to guest VMs. - Align with ARM platform architecture requirements for IOMMU support. By describing the SMMU in the device tree, the Linux IOMMU framework can probe and initialize it during boot. Devices in the system can then bind to the SMMU via the `iommus` property, enabling memory translation and protection features as expected. The following devices are updated to reference the SMMU: - NAND controller - DMA controller - SPI controller This change is a necessary step toward full enablement high-speed peripherals on Agilex5. Signed-off-by: Adrian Ng Ho Yin <adrianhoyin.ng@altera.com> Signed-off-by: Khairul Anuar Romli <khairul.anuar.romli@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-10-20arm64: dts: rockchip: add DTs for 100ASK DShanPi A1Hsun Lai2-0/+796
Add device tree for 100ASK DShanPi A1 with Rockchip RK3576 SoC (4x Cortex-A72, 4x Cortex-A53, Mali-G52 MC3 GPU, 6 TOPS NPU). Enables basic booting and connectivity. Link: https://wiki.dshanpi.org/en/docs/DshanPi-A1/intro/ The device contains the following hardware that is tested/working: - 32 or 64GB eMMC - SDMMC card slot - M.2 WiFi slot - 4 or 8GB of RAM - 2x 1Gbps Ethernet - 2x USB 3.2 Gen 1 Type-A ports - USB 3.0 port - HDMI port Signed-off-by: Hsun Lai <i@chainsx.cn> Link: https://patch.msgid.link/77BB123A1F1E3D11+20251014021623.286121-3-i@chainsx.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-20arm64: dts: rockchip: add LinkEase EasePi R1Liangbin Lian2-0/+624
LinkEase EasePi R1 [1] is a high-performance mini router. Specification: - Rockchip RK3568 - 2GB/4GB LPDDR4 RAM - 16GB on-board eMMC - 1x M.2 key for 2280 NVMe (PCIe 3.0) - 1x USB 3.0 Type-A - 1x USB 2.0 Type-C (for USB flashing) - 2x 1000 Base-T (native, RTL8211F) - 2x 2500 Base-T (PCIe, RTL8125B) - 1x HDMI 2.0 Output - 12v DC Jack - 1x Power key connected to PMIC - 2x LEDs (one static power supplied, one GPIO controlled) [1] https://doc.linkease.com/zh/guide/easepi-r1/hardware.html Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Liangbin Lian <jjm2473@gmail.com> Link: https://patch.msgid.link/20251014051226.64255-4-jjm2473@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-20KVM: s390: Replace sprintf with snprintf for buffer safetyJosephine Pfeiffer1-1/+1
Replace sprintf() with snprintf() when formatting debug names to prevent potential buffer overflow. The debug_name buffer is 16 bytes, and while unlikely to overflow with current PIDs, using snprintf() provides proper bounds checking. Signed-off-by: Josephine Pfeiffer <hi@josie.lol> [frankja@linux.ibm.com: Fixed subject prefix] Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2025-10-20arm64: dts: freescale: debix-som-a-bmb-08: Enable HDMI outputKieran Bingham1-0/+47
Enable the HDMI output on the Debix SOM A board, using the HDMI encoder present in the i.MX8MP SoC. Enable and configure all nodes required for the HDMI port usage. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-20arm64: dts: freescale: imx93-phyboard-segin: Add USB vbus regulatorsPrimoz Fiser1-0/+24
Add USB vbus regulators to silence the following kernel warnings: usb_phy_generic usbphynop1: dummy supplies not allowed for exclusive requests (id=vbus) usb_phy_generic usbphynop2: dummy supplies not allowed for exclusive requests (id=vbus) Because generic USB PHY driver requires exclusive vbus regulators since commit 75fd6485ccce ("usb: phy: generic: Get the vbus supply"). Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-07 10:54:48 +0300