summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-10-21arm64: dts: imx8mp-venice-gw702x: reduce RGMII CLK drive strengthTim Harvey
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 Harvey
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 Harvey
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 Carstens
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öppner
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 Carstens
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 Carstens
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 Richter
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 Pfeiffer
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 Pfeiffer
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 Pfeiffer
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 McBride
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 Stuebner
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 JAILLET
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 Shattow
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 Christopherson
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 Rubusch
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 Rubusch
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 Rubusch
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 Rubusch
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 Rubusch
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 Rubusch
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 Rubusch
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 Moger
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 Romli
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 Lai
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 Lian
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 Pfeiffer
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 Bingham
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 Fiser
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>
2025-10-20arm64: dts: freescale: imx93-phyboard-nash: Add USB vbus regulatorsPrimoz Fiser
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>
2025-10-20arm64: dts: tqma8mpql-mba8mpxl: Add MicIn routingAlexander Stein
MicIn is connected to IN3_L. Add routing including the Mic Bias. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-20ARM: dts: imx51-zii-rdu1: Fix audmux node namesJihed Chaibi
Rename the 'ssi2' and 'aud3' nodes to 'mux-ssi2' and 'mux-aud3' in the audmux configuration of imx51-zii-rdu1.dts to comply with the naming convention in imx-audmux.yaml. This fixes the following dt-schema warning: imx51-zii-rdu1.dtb: audmux@83fd0000 (fsl,imx51-audmux): 'aud3', 'ssi2' do not match any of the regexes: '^mux-[0-9a-z]*$', '^pinctrl-[0-9]+$' Fixes: ceef0396f367f ("ARM: dts: imx: add ZII RDU1 board") Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-20ARM: dts: imx6ull-engicam-microgea-rmm: fix report-rate-hz valueDario Binacchi
The 'report-rate-hz' property for the edt-ft5x06 driver was added and handled in the Linux kernel by me with patches [1] and [2] for this specific board. The v1 upstream version, which was the one applied to the customer's kernel, used the 'report-rate' property, which was written directly to the controller register. During review, the 'hz' suffix was added, changing its handling so that writing the value directly to the register was no longer possible for the M06 controller. Once the patches were accepted in mainline, I did not reapply them to the customer's kernel, and when upstreaming the DTS for this board, I forgot to correct the 'report-rate-hz' property value. The property must be set to 60 because this board uses the M06 controller, which expects the report rate in units of 10 Hz, meaning the actual value written to the register is 6. [1] 625f829586ea ("dt-bindings: input: touchscreen: edt-ft5x06: add report-rate-hz") [2] 5bcee83a406c ("Input: edt-ft5x06 - set report rate by dts property") Fixes: ffea3cac94ba ("ARM: dts: imx6ul: support Engicam MicroGEA RMM board") Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-20arm64: dts: rockchip: Enable PCIe controller on Radxa E20CYao Zi
Radxa E20C provides one of its GbE ports through RTL8111H connected to SoC's PCIe controller. Let's enable the controller and the PHY used by it to allow usage of the port. Signed-off-by: Yao Zi <ziyao@disroot.org> Link: https://patch.msgid.link/20250918153057.56023-4-ziyao@disroot.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-20arm64: dts: rockchip: Add PCIe Gen2x1 controller for RK3528Yao Zi
Describes the PCIe Gen2x1 controller integrated in RK3528 SoC. The SoC doesn't provide a separate MSI controller, thus the one integrated in designware PCIe IP must be used. Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Jonas Karlman <jonas@kwiboo.se> Link: https://patch.msgid.link/20250918153057.56023-3-ziyao@disroot.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-20arm64: dts: imx94: add DDR Perf Monitor nodeXu Yang
Add DDR Perf Monitor for i.MX94. Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-20arm64: dts: imx8mp-skov: support new 10" panel boardSteffen Trumtrar
This board is similar to the already upstream imx8mp-skov-recv-tian-g07017.dts but uses a different 10" panel with a different touch controller. Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-20ARM: dts: imx53-usbarmory: Replace license text comment with SPDX identifierBence Csókás
Replace verbatim license text with a `SPDX-License-Identifier`. The comment header mis-attributes this license to be "X11", but the license text does not include the last line "Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.". Therefore, this license is actually equivalent to the SPDX "MIT" license (confirmed by text diffing). Cc: Andrej Rosano <andrej@inversepath.com> Signed-off-by: Bence Csókás <csokas.bence@prolan.hu> Acked-by: Andrej Rosano <andrej.rosano@reversec.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-20arm64: dts: fsl-lx2160a: include rev2 chip's dtsFrank Li
The mass production lx2160 rev2 use designware PCIe Controller. Old Rev1 which use mobivel PCIe controller was not supported. Although uboot fixup can change compatible string fsl,lx2160a-pcie to fsl,ls2088a-pcie since 2019, it is quite confused and should correctly reflect hardware status in dtb. Change freescale's board to use rev2's dtsi firstly. Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-20KVM: s390: Remove unused return variable in kvm_arch_vcpu_ioctl_set_fpuThorsten Blum
kvm_arch_vcpu_ioctl_set_fpu() always returns 0 and the local return variable 'ret' is not used anymore. Remove it. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2025-10-20KVM: S390: Remove sca_lockChristoph Schlameuss
Since we are no longer switching from a BSCA to a ESCA we can completely get rid of the sca_lock. The write lock was only taken for that conversion. After removal of the lock some local code cleanups are possible. Signed-off-by: Christoph Schlameuss <schlameuss@linux.ibm.com> Suggested-by: Janosch Frank <frankja@linux.ibm.com> [frankja@linux.ibm.com: Added suggested-by tag as discussed on list] Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2025-10-20KVM: s390: Use ESCA instead of BSCA at VM initChristoph Schlameuss
All modern IBM Z and Linux One machines do offer support for the Extended System Control Area (ESCA). The ESCA is available since the z114/z196 released in 2010. KVM needs to allocate and manage the SCA for guest VMs. Prior to this change the SCA was setup as Basic SCA only supporting a maximum of 64 vCPUs when initializing the VM. With addition of the 65th vCPU the SCA was needed to be converted to a ESCA. Instead of allocating a BSCA and upgrading it for PV or when adding the 65th cpu we can always allocate the ESCA directly upon VM creation simplifying the code in multiple places as well as completely removing the need to convert an existing SCA. In cases where the ESCA is not supported (z10 and earlier) the use of the SCA entries and with that SIGP interpretation are disabled for VMs. This increases the number of exits from the VM in multiprocessor scenarios and thus decreases performance. The same is true for VSIE where SIGP is currently disabled and thus no SCA entries are used. The only downside of the change is that we will always allocate 4 pages for a 248 cpu ESCA instead of a single page for the BSCA per VM. In return we can delete a bunch of checks and special handling depending on the SCA type as well as the whole BSCA to ESCA conversion. With that behavior change we are no longer referencing a bsca_block in kvm->arch.sca. This will always be esca_block instead. By specifying the type of the sca as esca_block we can simplify access to the sca and get rid of some helpers while making the code clearer. KVM_MAX_VCPUS is also moved to kvm_host_types to allow using this in future type definitions. Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Christoph Schlameuss <schlameuss@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2025-10-20ARM: shmobile: defconfig: Refresh for v6.18-rc1Geert Uytterhoeven
Refresh the defconfig for Renesas ARM systems: - Drop CONFIG_SCHED_MC=y (auto-enabled since commit 7bd291abe2da09f5 ("sched: Unify the SCHED_{SMT,CLUSTER,MC} Kconfig")), - Disable CONFIG_SCHED_SMT (auto-enabled since commit 7bd291abe2da09f5 ("sched: Unify the SCHED_{SMT,CLUSTER,MC} Kconfig")), - Restore CONFIG_ARM_GT_INITIAL_PRESCALER_VAL=1 (default changed to zero (auto-detect) in commit 1c4b87c921fb158d ("clocksource/drivers/arm_global_timer: Add auto-detection for initial prescaler values")), - Disable CONFIG_RPCSEC_GSS_KRB5 (auto-enabled since commit d8e97cc476e33037 ("SUNRPC: Make RPCSEC_GSS_KRB5 select CRYPTO instead of depending on it")). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/d0fcc82fb294021bf96f8a490234165e15aadb43.1760530468.git.geert+renesas@glider.be
2025-10-20arm64: dts: exynos: gs101: add OPPsTudor Ambarus
Add operating performance points (OPPs). Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Tested-by: Peter Griffin <peter.griffin@linaro.org> # on gs101-oriole Link: https://patch.msgid.link/20250924-acpm-dvfs-dt-v4-3-3106d49e03f5@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-10-20arm64: dts: exynos: gs101: add CPU clocksTudor Ambarus
Add the GS101 CPU clocks exposed through the ACPM protocol. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Tested-by: Peter Griffin <peter.griffin@linaro.org> # on gs101-oriole Link: https://patch.msgid.link/20250924-acpm-dvfs-dt-v4-2-3106d49e03f5@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-10-20arm64: dts: exynos: gs101: add #clock-cells to the ACPM protocol nodeTudor Ambarus
Make the ACPM node a clock provider by adding the mandatory "#clock-cells" property, which allows devices to reference its clock outputs. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Tested-by: Peter Griffin <peter.griffin@linaro.org> # on gs101-oriole Link: https://patch.msgid.link/20250924-acpm-dvfs-dt-v4-1-3106d49e03f5@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-10-19csky: Remove compile warning for CONFIG_SMPGuo Ren (Alibaba DAMO Academy)
When CONFIG_SMP is enabled, there is a compile warning: arch/csky/kernel/smp.c:242:6: warning: no previous prototype for 'csky_start_secondary' [-Wmissing-prototypes] 242 | void csky_start_secondary(void) | ^~~~~~~~~~~~~~~~~~~~ Add a similar prototype with csky_start in sections.h. Signed-off-by: Guo Ren (Alibaba DAMO Academy) <guoren@kernel.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org>
2025-10-19Merge tag 'x86_urgent_for_v6.18_rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Reset the why-the-system-rebooted register on AMD to avoid stale bits remaining from previous boots - Add a missing barrier in the TLB flushing code to prevent erroneously not flushing a TLB generation - Make sure cpa_flush() does not overshoot when computing the end range of a flush region - Fix resctrl bandwidth counting on AMD systems when the amount of monitoring groups created exceeds the number the hardware can track * tag 'x86_urgent_for_v6.18_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/CPU/AMD: Prevent reset reasons from being retained across reboot x86/mm: Fix SMP ordering in switch_mm_irqs_off() x86/mm: Fix overflow in __cpa_addr() x86/resctrl: Fix miscount of bandwidth event when reactivating previously unavailable RMID
2025-10-19csky: Replace __ASSEMBLY__ with __ASSEMBLER__ in uapi headerThomas Huth
__ASSEMBLY__ is only defined by the Makefile of the kernel, so this is not really useful for uapi headers (unless the userspace Makefile defines it, too). Let's switch to __ASSEMBLER__ which gets set automatically by the compiler when compiling assembly code. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Guo Ren (Alibaba DAMO Academy) <guoren@kernel.org>
generated by cgit v1.2.3 (git 2.51.0) at 2026-10-22 14:41:48 +0000