summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-05-30drm/xe: drop redundant conversion to boolRaag Jadav
The result of integer comparison already evaluates to bool. No need for explicit conversion. No functional impact. Fixes: 0e414bf7ad01 ("drm/xe: Expose PCIe link downgrade attributes") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505292205.MoljmkjQ-lkp@intel.com/ Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250529160937.490147-1-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-05-30drm/xe/hwmon: Expose power sysfs entries based on firmware supportKarthik Poosa
Enable hwmon sysfs entries (power_xxx) only when GPU firmware supports it. Previously, these entries were created if the MMIO register was present. Now, we enable based on the data in the register. v2: Remove a unnecessary comment. (Rodrigo) Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250529163458.2354509-7-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-05-30drm/xe/hwmon: Read energy status from PMTKarthik Poosa
Read card and package energy status using pmt apis instead of xe_mmio for supported platforms. Enable Battlemage to read energy from PMT. v2: - Remove unused has_pmt_energy field. (Badal) - Use GENMASK to extract energy data. (Badal) v3: - Move PMT energy register offset and GENMASK to xe_pmt.h - Address review comments. (Jani) v4: - Remove unnecessary debug print. (Badal) v5: - Resolve an unused variable warning. - Add a return value check. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://lore.kernel.org/r/20250529163458.2354509-6-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-05-30drm/xe/hwmon: Expose powerX_cap_intervalKarthik Poosa
Expose powerX_cap_interval to manage burst power limit time window. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://lore.kernel.org/r/20250529163458.2354509-5-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-05-30drm/xe/hwmon: Add support to manage PL2 though mailboxKarthik Poosa
Add support to manage power limit PL2 (burst limit) through pcode mailbox commands. v2: - Update power1_cap definition in hwmon documentation. (Badal) - Clamp PL2 power limit to GPU firmware default value. v3: - Activate the power label when either the PL1 or PL2 power limit is enabled. v4: - Update description of pl2_on_boot variable to fix kernel-doc error. v5: - Remove unnecessary drm_warn. - Rectify powerX_label permission to read-only on platforms without mailbox power limits support. - Expose powerX_cap entries only on platforms with mailbox support. v6: - Improve commit message, refer to BIOS as GPU firmware. - Refer to card firmware as GPU firmware in code. - Remove unnecessary drm_dbg. - Print supported and unsupported power limits. (Rodrigo) - Enable powerN_cap/max_xxx entries only when power limits supported in GPU firmware. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://lore.kernel.org/r/20250529163458.2354509-4-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-05-30drm/xe/hwmon: Move card reactive critical power under channel cardKarthik Poosa
Move power2/curr2_crit to channel 1 i.e power1/curr1_crit as this represents the entire card critical power/current. v2: Update the date of curr1_crit also in hwmon documentation. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Fixes: 345dadc4f68b ("drm/xe/hwmon: Add infra to support card power and energy attributes") Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://lore.kernel.org/r/20250529163458.2354509-3-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-05-30drm/xe/hwmon: Add support to manage power limits though mailboxKarthik Poosa
Add support to manage power limits using pcode mailbox commands for supported platforms. v2: - Address review comments. (Badal) - Use mailbox commands instead of registers to manage power limits for BMG. - Clamp the maximum power limit to GPU firmware default value. v3: - Clamp power limit in write also for platforms with mailbox support. v4: - Remove unnecessary debug prints. (Badal) v5: - Update description of variable pl1_on_boot to fix kernel-doc error. v6: - Improve commit message, refer to BIOS as GPU firmware. - Change macro READ_PL_FROM_BIOS to READ_PL_FROM_FW. - Rectify drm_warn to drm_info. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Fixes: e90f7a58e659 ("drm/xe/hwmon: Add HWMON support for BMG") Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://lore.kernel.org/r/20250529163458.2354509-2-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-05-30bcachefs: Mark bch_errcode helpers __attribute__((const))Kent Overstreet
These don't access global memory or defer pointer arguments - this enables CSE optimizations. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-05-30bcachefs: Add missing printbuf_reset() in bch2_check_dirent_inode_dirent()Kent Overstreet
We were accidentally including the contents from the previous fsck_err(). Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-05-30bcachefs: sysfs/errorsKent Overstreet
Make the superblock error counters available in sysfs; the only other way they can be seen is 'show-super', but we don't write the superblock every time the error count gets incremented. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-05-30accel/qaic: Add Reliability, Accessibility, Serviceability (RAS)Jeff Hugo
AIC100 devices generates Reliability, Availability, Serviceability events via MHI QAIC_STATUS channel. Support such events and print a structured log with details of the events, and if the event describes an uncorrected error, reset the device to put it back into service. As these events may not all be reported via other mechanisms like AER, maintain counts of the number of errors observed for each type. Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Troy Hanson <quic_thanson@quicinc.com> Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Link: https://lore.kernel.org/r/20250516160634.1408309-1-jeff.hugo@oss.qualcomm.com
2025-05-30LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()Tianyang Zhang
ERROR INFO: CPU 25 Unable to handle kernel paging request at virtual address 0x0 ... Call Trace: [<900000000023c30c>] huge_pte_offset+0x3c/0x58 [<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438 [<900000000051fee8>] __get_user_pages+0xe0/0x4c8 [<9000000000522414>] faultin_page_range+0x84/0x380 [<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48 [<900000000056689c>] do_madvise+0x1bc/0x3e8 [<9000000000566df4>] sys_madvise+0x24/0x38 [<90000000015b9e88>] do_syscall+0x78/0x98 [<9000000000221f18>] handle_syscall+0xb8/0x158 In some cases, pmd may be NULL and rely on NULL as the return value for processing, so it is necessary to determine this situation here. Cc: stable@vger.kernel.org Fixes: bd51834d1cf6 ("LoongArch: Return NULL from huge_pte_offset() for invalid PMD") Signed-off-by: Tianyang Zhang <zhangtianyang@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-30LoongArch: Preserve firmware configuration when desiredHuacai Chen
If we must preserve the firmware resource assignments, claim the existing resources rather than reassigning everything. According to PCI Firmware Specification: if ACPI DSM#5 function returns 0, the OS must retain the resource allocation for PCI in the firmware; if ACPI DSM#5 function returns 1, the OS can ignore the resource allocation for PCI and reallocate it. Signed-off-by: Qihang Gao <gaoqihang@loongson.cn> Signed-off-by: Juxin Gao <gaojuxin@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-30LoongArch: Avoid using $r0/$r1 as "mask" for csrxchgHuacai Chen
When building kernel with LLVM there are occasionally such errors: In file included from ./include/linux/spinlock.h:59: In file included from ./include/linux/irqflags.h:17: arch/loongarch/include/asm/irqflags.h:38:3: error: must not be $r0 or $r1 38 | "csrxchg %[val], %[mask], %[reg]\n\t" | ^ <inline asm>:1:16: note: instantiated into assembly here 1 | csrxchg $a1, $ra, 0 | ^ To prevent the compiler from allocating $r0 or $r1 for the "mask" of the csrxchg instruction, the 'q' constraint must be used but Clang < 21 does not support it. So force to use $t0 in the inline asm, in order to avoid using $r0/$r1 while keeping the backward compatibility. Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/pull/141037 Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Suggested-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-30LoongArch: Introduce the numa_memblks conversionHuacai Chen
Commit 87482708210ff3333a ("mm: introduce numa_memblks") has moved numa_memblks from x86 to the generic code, but LoongArch was left out of this conversion. This patch introduces the generic numa_memblks for LoongArch. In detail: 1. Enable NUMA_MEMBLKS (but disable NUMA_EMU) in Kconfig; 2. Use generic definition for numa_memblk and numa_meminfo; 3. Use generic implementation for numa_add_memblk() and its friends; 4. Use generic implementation for numa_set_distance() and its friends; 5. Use generic implementation for memory_add_physaddr_to_nid() and its friends. Note: Disable NUMA_EMU because it needs more efforts and no obvious demand now. Tested-by: Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-30LoongArch: Increase max supported CPUs up to 2048Huacai Chen
Increase max supported CPUs up to 2048, including: 1. Increase CSR.CPUID register's effective width; 2. Define MAX_CORE_PIC (a.k.a. max physical ID) to 2048; 3. Allow NR_CPUS (a.k.a. max logical ID) to be as large as 2048; 4. Introduce acpi_numa_x2apic_affinity_init() to handle ACPI SRAT for CPUID >= 256. Note: The reason of increasing to 2048 rather than 4096/8192 is because the IPI hardware can only support 2048 as a maximum. Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-30LoongArch: Enable HAVE_ARCH_STACKLEAKYouling Tang
Add support for the stackleak feature. It initializes the stack with the poison value before returning from system calls which improves the kernel security. At the same time, disables the plugin in EFI stub code because EFI stub is out of scope for the protection. Tested on Loongson-3A5000 (enable GCC_PLUGIN_STACKLEAK and LKDTM): # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT # dmesg lkdtm: Performing direct entry STACKLEAK_ERASING lkdtm: stackleak stack usage: high offset: 320 bytes current: 448 bytes lowest: 1264 bytes tracked: 1264 bytes untracked: 208 bytes poisoned: 14528 bytes low offset: 64 bytes lkdtm: OK: the rest of the thread stack is properly erased Signed-off-by: Youling Tang <tangyouling@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-30LoongArch: Enable ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGSYuli Wang
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on LoongArch, covering the vdso. Link: https://lore.kernel.org/all/25bad37f-273e-4626-999c-e1890be96182@lucifer.local/ Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com> Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Reviewed-by: Jeff Xu <jeffxu@chromium.org> Tested-by: Yuli Wang <wangyuli@uniontech.com> Signed-off-by: Yuli Wang <wangyuli@uniontech.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-30LoongArch: Add SCHED_MC (Multi-core scheduler) supportTianyang Zhang
In order to achieve more reasonable load balancing behavior, add SCHED_MC (Multi-core scheduler) support. The LLC distribution of LoongArch now is consistent with NUMA node, the balancing domain of SCHED_MC can effectively reduce the situation where processes are awakened to smt_sibling. Co-developed-by: Hongliang Wang <wanghongliang@loongson.cn> Signed-off-by: Hongliang Wang <wanghongliang@loongson.cn> Signed-off-by: Tianyang Zhang <zhangtianyang@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-30LoongArch: Add some annotations in archhelpYouling Tang
- Add annotations to the kernel image. - Modify the annotations of make insatll. Signed-off-by: Youling Tang <tangyouling@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-30LoongArch: Using generic scripts/install.sh in `make install`Youling Tang
Use the generic script/install.sh to perform the make install operation. This will automatically generate the initrd file and modify the grub.cfg without manual intervention (The previous kernel image, config file and System.map will also be generated), similar to other architectures. Signed-off-by: Youling Tang <tangyouling@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-30LoongArch: Add a default install.shYouling Tang
As specified in scripts/install.sh, the priority order is as follows (from highest to lowest): ~/bin/installkernel /sbin/installkernel arch/loongarch/boot/install.sh Fallback to default install.sh if installkernel is not found. Signed-off-by: Youling Tang <tangyouling@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-30Merge commit 'core-entry-2025-05-25' into loongarch-nextHuacai Chen
LoongArch architecture changes for 6.16 modify some same files with the core-entry changes, so merge them to create a base to resolve conflicts.
2025-05-30asm-generic: Add sched.h inclusion in simd.hHuacai Chen
Commit 7ba8df47810f073 ("asm-generic: Make simd.h more resilient") causes a build error for PREEMPT_RT kernels: CC lib/crypto/sha256.o In file included from ./include/asm-generic/simd.h:6, from ./arch/loongarch/include/generated/asm/simd.h:1, from ./include/crypto/internal/simd.h:9, from ./include/crypto/internal/sha2.h:6, from lib/crypto/sha256.c:15: ./include/asm-generic/simd.h: In function 'may_use_simd': ./include/linux/preempt.h:111:34: error: 'current' undeclared (first use in this function) 111 | # define softirq_count() (current->softirq_disable_cnt & SOFTIRQ_MASK) | ^~~~~~~ ./include/linux/preempt.h:112:82: note: in expansion of macro 'softirq_count' 112 | # define irq_count() ((preempt_count() & (NMI_MASK | HARDIRQ_MASK)) | softirq_count()) | ^~~~~~~~~~~~~ ./include/linux/preempt.h:143:34: note: in expansion of macro 'irq_count' 143 | #define in_interrupt() (irq_count()) | ^~~~~~~~~ ./include/asm-generic/simd.h:18:17: note: in expansion of macro 'in_interrupt' 18 | return !in_interrupt(); | ^~~~~~~~~~~~ So add sched.h inclusion in simd.h to fix it. Fixes: 7ba8df47810f073 ("asm-generic: Make simd.h more resilient") Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-05-30crypto: s390/sha256 - rename module to sha256-s390Eric Biggers
When the s390 SHA-256 code is built as a loadable module, name it sha256-s390.ko instead of sha256.ko. This avoids a module name collision with crypto/sha256.ko and makes it consistent with the other architectures. We should consider making a single module provide all the SHA-256 library code, which would prevent issues like this. But for now this is the fix that's needed. Fixes: b9eac03edcf8 ("crypto: s390/sha256 - implement library instead of shash") Reported-by: Alex Williamson <alex.williamson@redhat.com> Closes: https://lore.kernel.org/r/20250529110526.6d2959a9.alex.williamson@redhat.com/ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-05-30drm/i915: drop intel_dpio_phy.h include from VLV IOSF SBJani Nikula
vlv_iosf_sb.c no longer depends on enum dpio_phy from intel_dpio_phy.h. Drop the include. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250527114854.3687469-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-30MIPS: loongson2ef: lemote-2f: add missing function prototypesRandy Dunlap
Add several missing function prototypes for lemote-2f to eliminate build warnings: arch/mips/loongson2ef/lemote-2f/machtype.c:10:13: warning: no previous prototype for 'mach_prom_init_machtype' [-Wmissing-prototypes] 10 | void __init mach_prom_init_machtype(void) arch/mips/loongson2ef/common/machtype.c:34:20: warning: no previous prototype for 'mach_prom_init_machtype' [-Wmissing-prototypes] 34 | void __weak __init mach_prom_init_machtype(void) arch/mips/loongson2ef/lemote-2f/pm.c:52:6: warning: no previous prototype for 'setup_wakeup_events' [-Wmissing-prototypes] 52 | void setup_wakeup_events(void) arch/mips/loongson2ef/lemote-2f/pm.c:90:5: warning: no previous prototype for 'wakeup_loongson' [-Wmissing-prototypes] 90 | int wakeup_loongson(void) arch/mips/loongson2ef/lemote-2f/pm.c:137:13: warning: no previous prototype for 'mach_suspend' [-Wmissing-prototypes] 137 | void __weak mach_suspend(void) arch/mips/loongson2ef/lemote-2f/pm.c:142:13: warning: no previous prototype for 'mach_resume' [-Wmissing-prototypes] 142 | void __weak mach_resume(void) Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: linux-mips@vger.kernel.org Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-05-30MIPS: loongson2ef: cs5536: add missing function prototypesRandy Dunlap
Add missing function prototypes for cs5536, mostly for PCI functions, and for init_mfgpt_clocksource(). arch/mips/loongson2ef/common/cs5536/cs5536_ide.c:15:6: warning: no previous prototype for 'pci_ide_write_reg' [-Wmissing-prototypes] 15 | void pci_ide_write_reg(int reg, u32 value) arch/mips/loongson2ef/common/cs5536/cs5536_ide.c:96:5: warning: no previous prototype for 'pci_ide_read_reg' [-Wmissing-prototypes] 96 | u32 pci_ide_read_reg(int reg) arch/mips/loongson2ef/common/cs5536/cs5536_ehci.c:15:6: warning: no previous prototype for 'pci_ehci_write_reg' [-Wmissing-prototypes] 15 | void pci_ehci_write_reg(int reg, u32 value) arch/mips/loongson2ef/common/cs5536/cs5536_ehci.c:75:5: warning: no previous prototype for 'pci_ehci_read_reg' [-Wmissing-prototypes] 75 | u32 pci_ehci_read_reg(int reg) arch/mips/loongson2ef/common/cs5536/cs5536_acc.c:15:6: warning: no previous prototype for 'pci_acc_write_reg' [-Wmissing-prototypes] 15 | void pci_acc_write_reg(int reg, u32 value) arch/mips/loongson2ef/common/cs5536/cs5536_acc.c:62:5: warning: no previous prototype for 'pci_acc_read_reg' [-Wmissing-prototypes] 62 | u32 pci_acc_read_reg(int reg) arch/mips/loongson2ef/common/cs5536/cs5536_ohci.c:15:6: warning: no previous prototype for 'pci_ohci_write_reg' [-Wmissing-prototypes] 15 | void pci_ohci_write_reg(int reg, u32 value) arch/mips/loongson2ef/common/cs5536/cs5536_ohci.c:70:5: warning: no previous prototype for 'pci_ohci_read_reg' [-Wmissing-prototypes] 70 | u32 pci_ohci_read_reg(int reg) arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:84:6: warning: no previous prototype for 'pci_isa_write_bar' [-Wmissing-prototypes] 84 | void pci_isa_write_bar(int n, u32 value) arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:110:5: warning: no previous prototype for 'pci_isa_read_bar' [-Wmissing-prototypes] 110 | u32 pci_isa_read_bar(int n) arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:134:6: warning: no previous prototype for 'pci_isa_write_reg' [-Wmissing-prototypes] 134 | void pci_isa_write_reg(int reg, u32 value) arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:228:5: warning: no previous prototype for 'pci_isa_read_reg' [-Wmissing-prototypes] 228 | u32 pci_isa_read_reg(int reg) arch/mips/loongson2ef/common/cs5536/cs5536_mfgpt.c:195:12: warning: no previous prototype for 'init_mfgpt_clocksource' [-Wmissing-prototypes] 195 | int __init init_mfgpt_clocksource(void) Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: linux-mips@vger.kernel.org Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-05-30net: usb: aqc111: debug info before sanitationOliver Neukum
If we sanitize error returns, the debug statements need to come before that so that we don't lose information. Signed-off-by: Oliver Neukum <oneukum@suse.com> Fixes: 405b0d610745 ("net: usb: aqc111: fix error handling of usbnet read calls") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-05-30Merge tag 'md-6.16-20250530' of ↵Jens Axboe
https://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux into block-6.16 Pull MD fixes from Yu: "- fix REQ_RAHEAD and REQ_NOWAIT IO err handling for raid1/10 - fix max_write_behind setting for dm-raid - some minor cleanups" * tag 'md-6.16-20250530' of https://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux: md/md-bitmap: remove parameter slot from bitmap_create() md/md-bitmap: cleanup bitmap_ops->startwrite() md/dm-raid: remove max_write_behind setting limit md/md-bitmap: fix dm-raid max_write_behind setting md/raid1,raid10: don't handle IO error for REQ_RAHEAD and REQ_NOWAIT
2025-05-30spi: bcm63xx-hsspi: fix shared resetÁlvaro Fernández Rojas
Some bmips SoCs (bcm6362, bcm63268) share the same SPI reset for both SPI and HSSPI controllers, so reset shouldn't be exclusive. Fixes: 0eeadddbf09a ("spi: bcm63xx-hsspi: add reset support") Reported-by: Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250529130915.2519590-3-noltari@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-30spi: bcm63xx-spi: fix shared resetÁlvaro Fernández Rojas
Some bmips SoCs (bcm6362, bcm63268) share the same SPI reset for both SPI and HSSPI controllers, so reset shouldn't be exclusive. Fixes: 38807adeaf1e ("spi: bcm63xx-spi: add reset support") Reported-by: Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250529130915.2519590-2-noltari@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-30KVM: arm64: vgic-debug: Avoid dereferencing NULL ITE pointerMarc Zyngier
Dan reports that iterating over a device ITEs can legitimately lead to a NULL pointer, and that the NULL check is placed *after* the pointer has already been dereferenced. Hoist the pointer check as early as possible and be done with it. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Fixes: 30deb51a677b ("KVM: arm64: vgic-its: Add debugfs interface to expose ITS tables") Link: https://lore.kernel.org/r/aDBylI1YnjPatAbr@stanley.mountain Cc: Jing Zhang <jingzhangos@google.com> Link: https://lore.kernel.org/r/20250530091647.1152489-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-30KVM: arm64: vgic-init: Plug vCPU vs. VGIC creation raceOliver Upton
syzkaller has found another ugly race in the VGIC, this time dealing with VGIC creation. Since kvm_vgic_create() doesn't sufficiently protect against in-flight vCPU creations, it is possible to get a vCPU into the kernel w/ an in-kernel VGIC but no allocation of private IRQs: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000d20 Mem abort info: ESR = 0x0000000096000046 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000103e4f000 [0000000000000d20] pgd=0800000102e1c403, p4d=0800000102e1c403, pud=0800000101146403, pmd=0000000000000000 Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP CPU: 9 UID: 0 PID: 246 Comm: test Not tainted 6.14.0-rc6-00097-g0c90821f5db8 #16 Hardware name: linux,dummy-virt (DT) pstate: 814020c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : _raw_spin_lock_irqsave+0x34/0x8c lr : kvm_vgic_set_owner+0x54/0xa4 sp : ffff80008086ba20 x29: ffff80008086ba20 x28: ffff0000c19b5640 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c4879bd0 x24: 000000000000001e x23: 0000000000000000 x22: 0000000000000000 x21: ffff0000c487af80 x20: ffff0000c487af18 x19: 0000000000000000 x18: 0000001afadd5a8b x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 x14: ffff0000c19b56c0 x13: 0030c9adf9d9889e x12: ffffc263710e1908 x11: 0000001afb0d74f2 x10: e0966b840b373664 x9 : ec806bf7d6a57cd5 x8 : ffff80008086b980 x7 : 0000000000000001 x6 : 0000000000000001 x5 : 0000000080800054 x4 : 4ec4ec4ec4ec4ec5 x3 : 0000000000000000 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 0000000000000d20 Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) kvm_vgic_set_owner+0x54/0xa4 kvm_timer_enable+0xf4/0x274 kvm_arch_vcpu_run_pid_change+0xe0/0x380 kvm_vcpu_ioctl+0x93c/0x9e0 __arm64_sys_ioctl+0xb4/0xec invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c Code: b9000841 d503201f 52800001 52800022 (88e17c02) ---[ end trace 0000000000000000 ]--- Plug the race by explicitly checking for an in-progress vCPU creation and failing kvm_vgic_create() when that's the case. Add some comments to document all the things kvm_vgic_create() is trying to guard against too. Reported-by: Alexander Potapenko <glider@google.com> Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Tested-by: Alexander Potapenko <glider@google.com> Link: https://lore.kernel.org/r/20250523194722.4066715-6-oliver.upton@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-30KVM: arm64: Unmap vLPIs affected by changes to GSI routing informationOliver Upton
KVM's interrupt infrastructure is dodgy at best, allowing for some ugly 'off label' usage of the various UAPIs. In one example, userspace can change the routing entry of a particular "GSI" after configuring irqbypass with KVM_IRQFD. KVM/arm64 is oblivious to this, and winds up preserving the stale translation in cases where vLPIs are configured. Honor userspace's intentions and tear down the vLPI mapping if affected by a "GSI" routing change. Make no attempt to reconstruct vLPIs if the new target is an MSI and just fall back to software injection. Tested-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20250523194722.4066715-5-oliver.upton@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-30KVM: arm64: Resolve vLPI by host IRQ in vgic_v4_unset_forwarding()Oliver Upton
The virtual mapping and "GSI" routing of a particular vLPI is subject to change in response to the guest / userspace. This can be pretty annoying to deal with when KVM needs to track the physical state that's managed for vLPI direct injection. Make vgic_v4_unset_forwarding() resilient by using the host IRQ to resolve the vgic IRQ. Since this uses the LPI xarray directly, finding the ITS by doorbell address + grabbing it's its_lock is no longer necessary. Note that matching the right ITS / ITE is already handled in vgic_v4_set_forwarding(), and unless there's a bug in KVM's VGIC ITS emulation the virtual mapping that should remain stable for the lifetime of the vLPI mapping. Tested-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20250523194722.4066715-4-oliver.upton@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-30KVM: arm64: Protect vLPI translation with vgic_irq::irq_lockOliver Upton
Though undocumented, KVM generally protects the translation of a vLPI with the its_lock. While this makes perfectly good sense, as the ITS itself contains the guest translation, an upcoming change will require twiddling the vLPI mapping in an atomic context. Switch to using the vIRQ's irq_lock to protect the translation. Use of the its_lock in vgic_v4_unset_forwarding() is preserved for now as it still needs to walk the ITS. Tested-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20250523194722.4066715-3-oliver.upton@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-30KVM: arm64: Use lock guard in vgic_v4_set_forwarding()Oliver Upton
The locking dance is about to get more interesting, switch the its_lock over to a lock guard to make it a bit easier to handle. Tested-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20250523194722.4066715-2-oliver.upton@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-30KVM: arm64: Mask out non-VA bits from TLBI VA* on VNCR invalidationMarc Zyngier
When handling a TLBI VA* instruction that potentially targets a VNCR page mapping, we fail to mask out the top bits that contain the ASID and TTL fields, hence potentially failing the VA check in the TLB code. An additional wrinkle is that we fail to sign extend the VA, again leading to failed VA checks. Fix both in one go by sign-extending the VA from bit 48, making it comparable to the way we interpret VNCR_EL2.BADDR. Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Link: https://lore.kernel.org/r/20250525175759.780891-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-30arm64: sysreg: Drag linux/kconfig.h to work around vdso build issueMarc Zyngier
Broonie reports that fed55f49fad18 ("arm64: errata: Work around AmpereOne's erratum AC04_CPU_23") breaks one of the vdso selftests (vdso_test_chacha) as it indirectly drags asm/sysreg.h. It is rather unfortunate (and worrying) that userspace gets built with non-UAPI headers. In any case, paper over the issue by dragging linux/kconfig.h in asm/sysreg.h. It is the right thing to do, at least from the kernel perspective. Reported-by: Mark Brown <broonie@kernel.org> Fixes: fed55f49fad18 ("arm64: errata: Work around AmpereOne's erratum AC04_CPU_23") Link: https://lore.kernel.org/r/aDCDGZ-G-nCP3hJI@finisterre.sirena.org.uk Cc: D Scott Phillips <scott@os.amperecomputing.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: Will Deacon <will@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250523170208.530818-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-30drm/gem: Inline drm_gem_pin() into PRIME helpersThomas Zimmermann
Inline drm_gem_pin() into its only caller drm_gem_map_attach() and update the documentation in the callback's purpose. Do the equivalent for drm_gem_unpin(). Also add stricter error checking on the involved locking. The pin operation in the GEM object functions is a helper for PRIME-exported buffer objects. Having drm_gem_pin() gives the impression of a general-purpose interface, which is not the case. Removing it makes the pin callback a bit harder to misuse. v2: - clarify comment on pin callback (Dmitry) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20250526132634.531789-5-tzimmermann@suse.de
2025-05-30drm/gem-vram: Un-export pin helpersThomas Zimmermann
There are no external callers of the gem-vram pin helpers. Hence unexport them. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20250526132634.531789-4-tzimmermann@suse.de
2025-05-30drm/gem-vram: Do not set pin and unpin callbacksThomas Zimmermann
Gem-vram helpers do not support PRIME dma-buf sharing. So nothing will ever call pin/unpin on its buffer objects. Do not set these callbacks in struct drm_gem_object_funcs. v2: - fix typo in commit description Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20250526132634.531789-3-tzimmermann@suse.de
2025-05-30drm/client: Do not pin in drm_client_buffer_vmap()Thomas Zimmermann
Pin and vmap are two distict operations. Do not mix them. The helper drm_client_buffer_vmap() maps the pages for fbdev-dma and fbdev-shmem. In both cases, the vmap operation ensures that the pages are available until the vunmap happens. And as the pages in DMA or SHMEM areas cannot be moved, there is no reason to call pin. Hence remove the pin call. Update drm_client_buffer_vunmap() accordingly. v2: - call 'locked' variants of GEM helpers (Dmitry) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20250526132634.531789-2-tzimmermann@suse.de
2025-05-30md/md-bitmap: remove parameter slot from bitmap_create()Yu Kuai
All callers pass in '-1' for 'slot', hence it can be removed. Link: https://lore.kernel.org/linux-raid/20250524061320.370630-6-yukuai1@huaweicloud.com Signed-off-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Xiao Ni <xni@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de>
2025-05-30md/md-bitmap: cleanup bitmap_ops->startwrite()Yu Kuai
bitmap_startwrite() always return 0, and the caller doesn't check return value as well, hence change the method to void. Also rename startwrite/endwrite to start_write/end_write, which is more in line with the usual naming convention. Link: https://lore.kernel.org/linux-raid/20250524061320.370630-4-yukuai1@huaweicloud.com Signed-off-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Xiao Ni <xni@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de>
2025-05-30md/dm-raid: remove max_write_behind setting limitYu Kuai
The comments said 'vaule in kB', while the value actually means the number of write_behind IOs. And since md-bitmap will automatically adjust the value to max COUNTER_MAX / 2, there is no need to fail early. Also move some macros that is only used md-bitmap.c. Link: https://lore.kernel.org/linux-raid/20250524061320.370630-15-yukuai1@huaweicloud.com Signed-off-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Xiao Ni <xni@redhat.com>
2025-05-30md/md-bitmap: fix dm-raid max_write_behind settingYu Kuai
It's supposed to be COUNTER_MAX / 2, not COUNTER_MAX. Link: https://lore.kernel.org/linux-raid/20250524061320.370630-14-yukuai1@huaweicloud.com Signed-off-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de>
2025-05-30md/raid1,raid10: don't handle IO error for REQ_RAHEAD and REQ_NOWAITYu Kuai
IO with REQ_RAHEAD or REQ_NOWAIT can fail early, even if the storage medium is fine, hence record badblocks or remove the disk from array does not make sense. This problem if found by lvm2 test lvcreate-large-raid, where dm-zero will fail read ahead IO directly. Fixes: e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags") Reported-and-tested-by: Mikulas Patocka <mpatocka@redhat.com> Closes: https://lore.kernel.org/all/34fa755d-62c8-4588-8ee1-33cb1249bdf2@redhat.com/ Link: https://lore.kernel.org/linux-raid/20250527081407.3004055-1-yukuai1@huaweicloud.com Signed-off-by: Yu Kuai <yukuai3@huawei.com>
2025-05-30Merge tag 'renesas-dts-for-v6.16-tag5' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt Renesas DTS updates for v6.16 (take five) - Reduce I2C2 clock frequency on the RZ/G3E SMARC SoM. * tag 'renesas-dts-for-v6.16-tag5' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: arm64: dts: renesas: rzg3e-smarc-som: Reduce I2C2 clock frequency Link: https://lore.kernel.org/r/cover.1748355530.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
generated by cgit (git 2.34.1) at 2025-09-17 08:27:26 +0000