summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-03wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o netdetectJohannes Berg
Clearly, from a user perspective, it must be valid to configure WoWLAN and then suspend while not connected to a network. Since mac80211 doesn't distinguish these cases and simply calls the driver to suspend whenever WoWLAN is configured, the driver has to cleanly handle the case where it's called for WoWLAN, it's not connected but there's also no netdetect configured. Remove the WARN_ON() and keep returning 1 to disconnect and then suspend. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260527230313.19720967372b.Iff30814510a26f9f609f98eeea3111c50c1afb31@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: cfg: Revert "wifi: iwlwifi: cfg: move the MODULE_FIRMWARE to ↵Shahar Tzarfati
the per-rf file" IWL_BZ_UCODE_CORE_MAX is undefined in cfg/rf-fm.c, this causes __stringify(core) to turn it into the literal token text, so MODULE_FIRMWARE entries are generated as "iwlwifi...-cIWL_BZ_UCODE_CORE_MAX.ucode", instead of the actual number. This reverts the commit below. Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com> Link: https://patch.msgid.link/20260527230313.a10bc3359dca.I446a1340c635f07aff3efaba5317635e010c156f@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: mld: set fast-balance scan for active EMLSRPagadala Yesu Anjaneyulu
While associated to MLD AP with active EMLSR, set all scan operations as fast-balance scans. The only exception is when a fragmented scan is planned (high traffic or low latency), in which case the fragmented scan is preserved. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Link: https://patch.msgid.link/20260527230313.32d278842b0e.Ia3d73e4085eefc4d3921e93de4107b2d6a6f922e@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: mld: support FW TLV for NAN max channel switch timeIsrael Kozitz
Add a new FW TLV (IWL_UCODE_TLV_FW_NAN_MAX_CHAN_SWITCH_TIME) that allows the firmware to specify the NAN maximum channel switch time in microseconds. When the TLV is present, use its value for the NAN device capability. Otherwise, fall back to the default of 4 milliseconds. Signed-off-by: Israel Kozitz <israel.kozitz@intel.com> Link: https://patch.msgid.link/20260527230313.e8ae1a3adacd.I15b933407ca3974a65047b63b4f9b00bed3520fb@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: mld: always allow mimo in NANMiri Korenblit
The mimo field of the sta command is badly named. It really carries the initial SMPS value as it is in the association request of the client station (when we are the AP). In NAN we don't have this information, just mark SMPS as disabled. Link: https://patch.msgid.link/20260527230313.abd136be474e.I9eb663d953b482236345ffbcb611f28facea83c1@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: move iwl_fw_rate_idx_to_plcp() to mvmJohannes Berg
It's only needed by mvm, so there's no need to have it in iwlwifi and export it, just move it to mvm itself. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260527230313.87769f13c7d7.I3875d768694b9484317a3253f479a2a2100244f4@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: mvm: rename iwl_mvm_mac80211_idx_to_hwrate()Johannes Berg
Given that we now use v3 rates with FW index throughout, _to_hwrate() is confusing, since the hardware still uses the PLCP value, the driver just doesn't see that now (as it talks to firmware, not hardware.) Rename this to iwl_mvm_rate_idx_to_fw_idx() to more clearly indicate what it's doing. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260527230313.a60c8aea5b6c.I6af48d5d9748e184eed9d3437d312291cab61d7f@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: fix STEP_URM register address for SC devicesMoriya Itzchaki
The CNVI_PMU_STEP_FLOW register address differs between device families. For SC and newer devices, the register is at 0xA2D688, while for BZ devices it's at 0xA2D588. Signed-off-by: Moriya Itzchaki <moriya.itzchaki@intel.com> Link: https://patch.msgid.link/20260527230313.f0c115c4f74e.I3c66b2e39a97f754e853ac7e7dba8e433523619e@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: mld: fix smatch warningMiri Korenblit
We dereference the mld_sta pointer before checking for NULL. But we do check the sta pointer, and sta != NULL means mld_sta != NULL, so there is no real issue. Fix it anyway to silence the warning. Link: https://patch.msgid.link/20260527200512.506707-2-miriam.rachel.korenblit@intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: remove mvm prefix from marker commandMiri Korenblit
This command is sent in other opmodes as well. Remove the mvm prefix. Link: https://patch.msgid.link/20260527230313.290e4d9db14a.Ia4edc64dacc8e298ab7817ab5c37843e92698b8d@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: remove stale commentMiri Korenblit
iwl_pcie_set_hw_ready still returns the return value of iwl_poll_bits, but the latter one no longer returns the time elapsed until success, now it returns either success or failure. Remove the comment entirely. Link: https://patch.msgid.link/20260527230313.ae42da7924ec.I1a92266621dc0033afa80f022d4c45e91674fedb@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: fw: cut down NIC wakeups during dumpJohannes Berg
Currently, the dump code attempts to dump any number of memories and register banks, as defined by the firmware. Especially when the device is failing, this can lead to excessive time spent attempting to acquire NIC access over and over again. Improve the code to only attempt to acquire NIC access once or twice, but using the new memory dump functions that may drop the spinlock etc. Mark all dump regions that require NIC access, and skip them if we couldn't obtain that. In order to avoid CPU latency due to the increased time holding the spinlock (and possibly disabling softirqs), drop locks and call cond_resched() after each section (if holding NIC access) but don't release HW NIC access. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260527230313.bec886142cc8.I41f2eaf2403b38147504d5dab0a7414de2699adc@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03wifi: iwlwifi: add support for AX231Emmanuel Grumbach
AX231 is a device that is based on AX211 that doesn't support 6E and its bandwidth is limited to 80 MHz. Just reuse the radio config from AX203 which has the exact same characteristics. It has a specific subdevice ID to allow the driver to differentiate between AX211 and AX231. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260512082114.0685ed313987.Ibcfa24e196ac778405d2843f0984b66ca167704e@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-06-03iio: chemical: scd30: Replace manual locking with RAII lockingMaxwell Doose
scd30_core.c currently uses manual mutex_lock() and mutex_unlock() calls. Replace them with the newer guard(mutex)() for cleaner RAII patterns and to improve maintainability. Add new helper function scd30_trigger_handler_helper() containing the critical section for scd30_trigger_handler(). In addition, small refactor to replace "?:" operator with regular if/else returns. Signed-off-by: Maxwell Doose <m32285159@gmail.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2026-06-03ASoC: amd: remove unused machineMark Brown
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says: This patch-set removes unused machine Link: https://patch.msgid.link/877bogce4k.wl-kuninori.morimoto.gx@renesas.com
2026-06-03ASoC: amd: ps-mach: remove unused machineKuninori Morimoto
Not used, remove it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/8733z4ce3i.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-03ASoC: amd: acp6x-mach: remove unused machineKuninori Morimoto
Not used, remove it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/874ijkce3m.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-03ASoC: amd: acp3x-rn: remove unused machineKuninori Morimoto
Not used, remove it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/875x40ce3s.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-03s390/percpu: Provide arch_this_cpu_write() implementationHeiko Carstens
Provide an s390 specific implementation of arch_this_cpu_write() instead of the generic variant. The generic variant uses a quite expensive raw_local_irq_save() / raw_local_irq_restore() pair. Get rid of this by providing an own variant which makes use of the new percpu code section infrastructure. With this the text size of the kernel image is reduced by ~1k (defconfig). Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/percpu: Provide arch_this_cpu_read() implementationHeiko Carstens
Provide an s390 specific implementation of arch_this_cpu_read() instead of the generic variant. The generic variant uses preempt_disable() / preempt_enable() pair and READ_ONCE(). Get rid of the preempt_disable() / preempt_enable() pairs by providing an own variant which makes use of the new percpu code section infrastructure. With this the text size of the kernel image is reduced by ~1k (defconfig). Also 87 generated preempt_schedule_notrace() function calls within the kernel image (modules not counted) are removed. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/percpu: Use new percpu code section for arch_this_cpu_[and|or]()Heiko Carstens
Convert arch_this_cpu_[and|or]() to make use of the new percpu code section infrastructure. There is no user of this_cpu_and() and only one user of this_cpu_or() within the kernel. Therefore this conversion has hardly any effect, and also removes only preempt_schedule_notrace() function call. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/percpu: Use new percpu code section for arch_this_cpu_add_return()Heiko Carstens
Convert arch_this_cpu_add_return() to make use of the new percpu code section infrastructure. With this the text size of the kernel image is reduced by ~4k (defconfig). Also 66 generated preempt_schedule_notrace() function calls within the kernel image (modules not counted) are removed. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/percpu: Use new percpu code section for arch_this_cpu_add()Heiko Carstens
Convert arch_this_cpu_add() to make use of the new percpu code section infrastructure. With this the text size of the kernel image is reduced by ~76kb (defconfig). Also more than 5300 generated preempt_schedule_notrace() function calls within the kernel image (modules not counted) are removed. With: DEFINE_PER_CPU(long, foo); void bar(long a) { this_cpu_add(foo, a); } Old arch_this_cpu_add() looks like this: 00000000000000c0 <bar>: c0: c0 04 00 00 00 00 jgnop c0 <bar> c6: eb 01 03 a8 00 6a asi 936,1 cc: c4 18 00 00 00 00 lgrl %r1,cc <bar+0xc> ce: R_390_GOTENT foo+0x2 d2: e3 10 03 b8 00 08 ag %r1,952 d8: eb 22 10 00 00 e8 laag %r2,%r2,0(%r1) de: eb ff 03 a8 00 6e alsi 936,-1 e4: a7 a4 00 05 jhe ee <bar+0x2e> e8: c0 f4 00 00 00 00 jg e8 <bar+0x28> ea: R_390_PC32DBL __s390_indirect_jump_r14+0x2 ee: c0 f4 00 00 00 00 jg ee <bar+0x2e> f0: R_390_PLT32DBL preempt_schedule_notrace+0x2 New arch_this_cpu_add() looks like this: 00000000000000c0 <bar>: c0: c0 04 00 00 00 00 jgnop c0 <bar> c6: c4 38 00 00 00 00 lgrl %r3,c6 <bar+0x6> c8: R_390_GOTENT foo+0x2 cc: b9 04 00 43 lgr %r4,%r3 d0: eb 00 43 c0 00 52 mviy 960(%r0),4 d6: e3 40 03 b8 00 08 ag %r4,952 dc: eb 52 40 00 00 e8 laag %r5,%r2,0(%r4) e2: eb 00 03 c0 00 52 mviy 960,0 e8: c0 f4 00 00 00 00 jg e8 <bar+0x28> ea: R_390_PC32DBL __s390_indirect_jump_r14+0x2 Note that the conditional function call is removed. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/percpu: Add missing do { } while (0) constructsHeiko Carstens
Add missing do { } while (0) constructs in order to avoid potential build failures. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260319120503.4046659-1-hca%40linux.ibm.com Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/percpu: Infrastructure for more efficient this_cpu operationsHeiko Carstens
With the intended removal of PREEMPT_NONE this_cpu operations based on atomic instructions, guarded with preempt_disable()/preempt_enable() pairs become more expensive: the preempt_disable() / preempt_enable() pairs are not optimized away anymore during compile time. In particular the conditional call to preempt_schedule_notrace() after preempt_enable() adds additional code and register pressure. E.g. this simple C code sequence DEFINE_PER_CPU(long, foo); long bar(long a) { return this_cpu_add_return(foo, a); } generates this code: 11a976: eb af f0 68 00 24 stmg %r10,%r15,104(%r15) 11a97c: b9 04 00 ef lgr %r14,%r15 11a980: b9 04 00 b2 lgr %r11,%r2 11a984: e3 f0 ff c8 ff 71 lay %r15,-56(%r15) 11a98a: e3 e0 f0 98 00 24 stg %r14,152(%r15) 11a990: eb 01 03 a8 00 6a asi 936,1 <- __preempt_count_add(1) 11a996: c0 10 00 d2 ac b5 larl %r1,1b70300 <- address of percpu var 11a9a0: e3 10 23 b8 00 08 ag %r1,952 <- add percpu offset 11a9a6: eb ab 10 00 00 e8 laag %r10,%r11,0(%r1) <- atomic op 11a9ac: eb ff 03 a8 00 6e alsi 936,-1 <- __preempt_count_dec_and_test() 11a9b2: a7 54 00 05 jnhe 11a9bc <bar+0x4c> 11a9b6: c0 e5 00 76 d1 bd brasl %r14,ff4d30 <preempt_schedule_notrace> 11a9bc: b9 e8 b0 2a agrk %r2,%r10,%r11 11a9c0: eb af f0 a0 00 04 lmg %r10,%r15,160(%r15) 11a9c6 07 fe br %r14 Even though the above example is more or less the worst case, since the branch to preempt_schedule_notrace() requires a stackframe, which otherwise wouldn't be necessary, there is also the conditional jnhe branch instruction. Get rid of the conditional branch with the following code sequence: 11a8e6: c0 30 00 d0 c5 0d larl %r3,1b33300 11a8ec: b9 04 00 43 lgr %r4,%r3 11a8f0: eb 00 43 c0 00 52 mviy 960,4 11a8f6: e3 40 03 b8 00 08 ag %r4,952 11a8fc: eb 52 40 00 00 e8 laag %r5,%r2,0(%r4) 11a902: eb 00 03 c0 00 52 mviy 960,0 11a908: b9 08 00 25 agr %r2,%r5 11a90c 07 fe br %r14 The general idea is that this_cpu operations based on atomic instructions are guarded with mviy instructions: - The first mviy instruction writes the register number, which contains the percpu address variable to lowcore. This also indicates that a percpu code section is executed. - The first instruction following the mviy instruction must be the ag instruction which adds the percpu offset to the percpu address register. - Afterwards the atomic percpu operation follows. - Then a second mviy instruction writes a zero to lowcore, which indicates the end of the percpu code section. - In case of an interrupt/exception/nmi the register number which was written to lowcore is copied to the exception frame (pt_regs), and a zero is written to lowcore. - On return to the previous context it is checked if a percpu code section was executed (saved register number not zero), and if the process was migrated to a different cpu. If the percpu offset was already added to the percpu address register (instruction address does _not_ point to the ag instruction) the content of the percpu address register is adjusted so it points to percpu variable of the new cpu. Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/zcrypt: Replace get_zeroed_page() with kzalloc()Mike Rapoport (Microsoft)
zcrypt_rng_device_add() allocates a buffer for the software random number generator data cache. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of get_zeroed_page() with kzalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/trng: Replace __get_free_page() with kmalloc()Mike Rapoport (Microsoft)
trng_read() allocates a temporary staging buffer for CPACF TRNG random data before copying it to userspace. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/qeth: Replace get_zeroed_page() with kzalloc()Mike Rapoport (Microsoft)
qeth_get_trap_id() allocates a temporary buffer for STSI system information queries used to build trap identification strings. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of get_zeroed_page() with kzalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Acked-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/hvc_iucv: Replace get_zeroed_page() with kzalloc()Mike Rapoport (Microsoft)
hvc_iucv_alloc() allocates a send staging buffer for accumulating outbound terminal characters before they are copied into a separate IUCV message buffer for transmission to the hypervisor. The staging buffer itself is never passed to any IUCV function. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of get_zeroed_page() with kzalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/dasd: Replace get_zeroed_page() with kzalloc()Mike Rapoport (Microsoft)
DASD driver uses get_zeroed_page() to allocate pages for the Extended Error Reporting software ring buffer and for a scratch buffer for formatting sense dump diagnostic text. These buffers can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of get_zeroed_page() with kzalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/con3270: Replace __get_free_page() with kmalloc()Mike Rapoport (Microsoft)
con3270_alloc_view() allocates a staging buffer used to assemble 3270 datastream content before it is copied into channel program requests. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/fpu: Move GR_NUM / VX_NUM macros to separate header fileHeiko Carstens
Move GR_NUM / VX_NUM macros to separate insn-common-asm.h header file so they can be reused for non-fpu insn constructs. Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Steffen Eiden <seiden@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/fpu: Shorten GR_NUM / VX_NUM macrosHeiko Carstens
Use the ".irp" directive to get rid of all the repeated ".ifc" usages in fpu-insn-asm.h. Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Steffen Eiden <seiden@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/ap/zcrypt: Rearrange fields within AP and zcrypt structsHarald Freudenberger
Rearrange some fields within AP and zcrypt structs to reduce memory consumption and unused holes with the help of pahole analysis of the code. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Finn Callies <fcallies@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: select FSP Chain of Trust versionJohn Hubbard
The FSP Chain of Trust handshake is versioned: Hopper speaks version 1 and Blackwell speaks version 2. Provide the version through the FSP HAL so the boot message carries the value FSP expects, and so chipsets that do not use FSP need not express a version at all. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-5-d9f3a06939e0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: add FSP send/receive messagingJohn Hubbard
FSP exchanges are request/response: the driver sends an MCTP/NVDM message and must match the reply against the request before acting on it. Add the synchronous send-and-wait path that validates the response transport and message headers and confirms the reply corresponds to the request that was sent. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-4-d9f3a06939e0@nvidia.com [acourbot: make `MessageToFsp` private.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: add MCTP/NVDM protocol types for firmware communicationJohn Hubbard
Add the MCTP (Management Component Transport Protocol) and NVDM (NVIDIA Data Model) wire-format types used for communication between the kernel driver and GPU firmware processors. This includes typed MCTP transport headers, NVDM message headers, and NVDM message type identifiers. Both the FSP boot path and the upcoming GSP RPC message queue share this protocol layer. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-3-d9f3a06939e0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: add FSP message infrastructureJohn Hubbard
FSP communication uses a pair of non-circular queues in the FSP falcon's EMEM, one for messages from the driver to FSP and one for replies, with the driver polling for response data. Add the queue registers and the low-level helpers used by the higher-level FSP message layer. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-2-d9f3a06939e0@nvidia.com [acourbot: align register fields names with OpenRM.] [acourbot: represent registers as arrays of 8 instances, as per OpenRM.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: add FSP falcon EMEM operationsJohn Hubbard
Add external memory (EMEM) read/write operations to the GPU's FSP falcon engine. These operations use Falcon PIO (Programmed I/O) to communicate with the FSP through indirect memory access. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-1-d9f3a06939e0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03selftests: livepatch: set LC_ALL=C to fix locale-dependent test failureQiang Ma
When executing the command "make -C tools/testing/selftests TARGETS=livepatch run_tests", the following error message was reported. TEST: livepatch interaction with ftrace_enabled sysctl ... not ok ... livepatch: sysctlo : setting key "kernel.ftrace_enabled": Device or resource busy livepatch: sysctl: setting key "kernel.ftrace_enabled": 设备或资源忙 ... ERROR: livepatch kselftest(s) failed not ok 5 selftests: livepatch: test-ftrace.sh # exit=1 To fix it, set LC_ALL=C. Signed-off-by: Qiang Ma <maqianga@uniontech.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Acked-by: Petr Mladek <pmladek@suse.com> Link: https://patch.msgid.link/20260527095929.1504032-1-maqianga@uniontech.com Signed-off-by: Petr Mladek <pmladek@suse.com>
2026-06-03KVM: riscv: Fast-path dirty logging write faultsJinyu Tang
With dirty logging enabled, guest writes often fault on an existing 4K G-stage leaf that was write-protected only for dirty tracking. The slow path still performs the full fault handling flow and takes mmu_lock for write, even though the page-table shape does not change. x86 handles the analogous case in its fast page fault path by atomically making a writable SPTE writable again when the fault is only a write-protection fault. Add the same style of fast path for RISC-V. If a write fault hits an existing 4K leaf in a writable dirty-log memslot, mark the page dirty and atomically set the PTE writable and dirty under the read side of mmu_lock. The dirty bitmap is updated before the PTE becomes writable again. The PTE D bit is also set so systems that trap on a clear D bit do not fall back to the slow path for a writable but clean PTE. Signed-off-by: Jinyu Tang <tjytimi@163.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260517153427.94889-6-tjytimi@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-03KVM: riscv: Update G-stage PTE permissions atomicallyJinyu Tang
When a fault hits an existing G-stage leaf with the same PFN, KVM only needs to update the PTE permissions. This path will be used by read-side fault handling, so it must not overwrite a concurrent PTE update. Use the cmpxchg helper when relaxing permissions on an existing leaf, following the same concurrency model used by x86 for atomic SPTE permission updates. Retry if another CPU changed the PTE first, and use cpu_relax() while spinning. Signed-off-by: Jinyu Tang <tjytimi@163.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260517153427.94889-5-tjytimi@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-03KVM: riscv: Add a G-stage PTE cmpxchg helperJinyu Tang
Permission-only G-stage PTE updates can run in parallel once they are moved to the read side of mmu_lock. Plain set_pte() is not enough for that case because another CPU may update the same PTE first. x86 handles the same class of SPTE races with cmpxchg-based updates in its fast page fault and TDP MMU paths. Add a small RISC-V helper for atomic G-stage PTE updates. The helper reports contention to the caller and flushes the target range only when the PTE value actually changes. Signed-off-by: Jinyu Tang <tjytimi@163.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260517153427.94889-4-tjytimi@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-03KVM: riscv: Use an rwlock for mmu_lockJinyu Tang
RISC-V KVM currently uses a spinlock for mmu_lock. That serializes all G-stage MMU operations, including permission-only updates that do not allocate or free page-table pages. Use KVM's rwlock form of mmu_lock, as x86 and arm64 already do. Keep the existing map, unmap and teardown paths on the write side. This prepares RISC-V for read-side handling of G-stage permission updates. Signed-off-by: Jinyu Tang <tjytimi@163.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260517153427.94889-3-tjytimi@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-03KVM: riscv: Rely on common MMU notifier lockingJinyu Tang
The common KVM invalidation paths call kvm_unmap_gfn_range() with mmu_lock already held for write. For the standard MMU notifier path, the call chain is: kvm_mmu_notifier_invalidate_range_start() kvm_handle_hva_range() kvm_unmap_gfn_range() kvm_mmu_notifier_invalidate_range_start() leaves range.lockless clear. kvm_handle_hva_range() therefore takes KVM_MMU_LOCK(kvm) before invoking the handler. The guest_memfd path has the same locking contract: __kvm_gmem_invalidate_begin() kvm_mmu_unmap_gfn_range() kvm_unmap_gfn_range() __kvm_gmem_invalidate_begin() explicitly takes KVM_MMU_LOCK(kvm) before calling kvm_mmu_unmap_gfn_range(). So remove the local trylock and make the common locking contract explicit with lockdep_assert_held_write() like x86. Signed-off-by: Jinyu Tang <tjytimi@163.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260517153427.94889-2-tjytimi@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-03KVM: selftests: Add a test for gPAT handling in L2Yosry Ahmed
When KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT is disabled, verify that KVM correctly virtualizes the host PAT MSR and the guest PAT register for nested SVM guests. With nested NPT disabled: * L1 and L2 share the same PAT * The vmcb12.g_pat is ignored With nested NPT enabled: * An invalid g_pat in vmcb12 causes VMEXIT_INVALID * RDMSR(IA32_PAT) from L2 returns the value of the guest PAT register * WRMSR(IA32_PAT) from L2 is reflected in vmcb12's g_pat on VMEXIT * RDMSR(IA32_PAT) from L1 returns the value of the host PAT MSR Verify that save/restore with the vCPU in guest mode behaves as expected in both cases, e.g. preserves both hPAT and gPAT when NPT is enabled. Originally-by: Jim Mattson <jmattson@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> [sean: use even fancier macro shenanigans] Link: https://patch.msgid.link/20260528231052.404737-1-seanjc@google.com [sean: avoid use of goto, print skips] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: selftests: Add guest_memfd regression test signed offset+size bugSean Christopherson
Add a regression (and proof-of-bug) testcase to ensure KVM rejects an offset+size that would result in a negative value when computed as a signed 64-bit value. KVM had a flaw where it would allow binding a memslot to a guest_memfd instance even with a wildly out-of-range offset, if the offset and size were both positive values, but the combined offset+size was negative. Use "0x7fffffffffffffffull - page_size", i.e. "INT64_MAX - page_size", for the offset as the size of the guest_memfd file must be at least page_size (KVM requires memslots and gmem files to be host page-size aligned). I.e. "INT64_MAX - page_size + size" is guaranteed to generate an offset+size that is negative when converted to a signed 64-bit value *and* honors KVM's alignment requirements. Reviewed-by: Ackerley Tng <ackerleytng@google.com> Tested-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260602170921.1304394-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: selftests: Expand the guest_memfd test macros to allow passing the VMSean Christopherson
Expand the gmem test macros to allow passing the VM to testcases, without needing to plumb the VM into _every_ testcase, as the vast majority of testcases only need the fd and size. No functional change intended. Reviewed-by: Ackerley Tng <ackerleytng@google.com> Tested-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260602170921.1304394-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: guest_memfd: Treat memslot binding offset+size as unsigned valuesSean Christopherson
When binding a memslot to a guest_memfd file, treat the offset and size as unsigned values to fix a bug where the sum of the two can result in a false negative when checking for overflow against the size of the file. Passing unsigned values also avoids relying on somewhat obscure checks in other flows for safety, and tracks the offset and size as they are intended to be tracked, as unsigned values. On 64-bit kernels, the number of pages a memslot contains and thus the size (and offset) of its guest_memfd binding are unsigned 64-bit values. Taking the offset+size as an loff_t instead of a uoff_t inadvertently converts the unsigned value to a signed value if the offset and/or size is massive. Locally storing the offset and size as signed values is benign in and of itself (though even that is *extremely* difficult to discern), but operating on their sum is not. For the offset, KVM explicitly checks against a negative value, which might seem like a bug as KVM could incorrectly reject a legitimate binding, but that's not actually the case as KVM_CREATE_GUEST_MEMFD takes a signed value for its size, i.e. a would-be-negative offset is also greater than the maximum possible size of any guest_memfd file. Regarding the size, while KVM lacks an explicit check for a negative value, i.e. seemingly has a flawed overflow check, KVM restricts the number of pages in a single memslot to the largest positive signed 32-bit value: if (id < KVM_USER_MEM_SLOTS && (mem->memory_size >> PAGE_SHIFT) > KVM_MEM_MAX_NR_PAGES) return -EINVAL; and so that maximum "size" will ever be is 0x7fffffff000. The sum of the two is, however, problematic. While the size is restricted by KVM's memslot logic, the offset is not, i.e. the offset is completely unchecked until the "offset + size > i_size_read(inode)" check. If the offset is the (nearly) largest possible _positive_ value, then adding size to the offset can result in a signed, negative 64-bit value. When compared against the size of the file (guaranteed to be positive), the negative sum is always smaller, and KVM incorrectly allows the absurd offset. Opportunistically add missing includes in kvm_mm.h (instead of relying on its parents). Fixes: a7800aa80ea4 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") Cc: stable@vger.kernel.org Cc: Ackerley Tng <ackerleytng@google.com> Reviewed-by: Michael Roth <michael.roth@amd.com> Reviewed-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260602170921.1304394-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86: Remove defunct kvm_load_segment_descriptor() declaration.Sean Christopherson
Remove a dead kvm_load_segment_descriptor() declaration, no functional change intended. Reviewed-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260529222223.870923-30-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>