summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-10-10wifi: ath12k: Add direct HAL pointer in ath12k_dpPavankumar Nandeshwar
Add a direct pointer to the HAL context in ath12k_dp. Since ath12k_dp is frequenctly used in the per-packet data path, this avoids the need to access the HAL handle through the ab pointer, reducing indirection in the per-packet data path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Pavankumar Nandeshwar <quic_pnandesh@quicinc.com> Signed-off-by: Ripan Deuri <quic_rdeuri@quicinc.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251009111045.1763001-7-quic_rdeuri@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-10-10wifi: ath12k: Move hal_params and regs to hal from hwPavankumar Nandeshwar
Move hal_params and regs to hal structure from the hw structure, since these parameters are used by hal layer and make corresponding initializations in hal_init. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Pavankumar Nandeshwar <quic_pnandesh@quicinc.com> Signed-off-by: Ripan Deuri <quic_rdeuri@quicinc.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251009111045.1763001-6-quic_rdeuri@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-10-10wifi: ath12k: Move wbm_rbm_map to hw specific hal filesPavankumar Nandeshwar
Move wbm_rbm_map from common hal file to hw specific hal files, since these implementations are specific and configurable for each hardware. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Pavankumar Nandeshwar <quic_pnandesh@quicinc.com> Signed-off-by: Ripan Deuri <quic_rdeuri@quicinc.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251009111045.1763001-5-quic_rdeuri@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-10-10wifi: ath12k: Initialize hal_ops through hal_initPavankumar Nandeshwar
Modularize the HAL layer by moving hal_ops from ab->hw_params into the ab->hal. This reduces indirection and allows data path to access HAL ops directly through the HAL context. Initialize hal_ops via hal_init using a const table ath12k_hw_version_map. This approach will be extended to register other HAL parameters during init. Remove ab->hw_params->hal_ops as it is no longer needed. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Pavankumar Nandeshwar <quic_pnandesh@quicinc.com> Signed-off-by: Ripan Deuri <quic_rdeuri@quicinc.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251009111045.1763001-4-quic_rdeuri@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-10-10wifi: ath12k: Initialize desc_size through hal_initPavankumar Nandeshwar
Currently desc_size uses a dedicated hal_ops API for initialization. Combine it with other hal_params to be initialized in a single API "hal_init" during probe time using a static array. hal_init will be used as the common API to initialize all hal parameters during the probe. Add hal.c file to add hal definitions that are wifi7 specific but common between qca and wcn chipsets. Add hal.h header to add wifi7 specific prototypes/Macros etc Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Pavankumar Nandeshwar <quic_pnandesh@quicinc.com> Signed-off-by: Ripan Deuri <quic_rdeuri@quicinc.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251009111045.1763001-3-quic_rdeuri@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-10-10wifi: ath12k: Move srng config and hal_ops to hw specific hal filesPavankumar Nandeshwar
Move srng config and hal_ops from common hal file to hw specific hal files, since these implementations are specific and configurable for each hardware Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Pavankumar Nandeshwar <quic_pnandesh@quicinc.com> Signed-off-by: Ripan Deuri <quic_rdeuri@quicinc.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251009111045.1763001-2-quic_rdeuri@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-10-10drm/xe/migrate: Fix an error pathThomas Hellström
The exhaustive eviction accidently changed an error path goto to a return. Fix this. Fixes: 59eabff2a352 ("drm/xe: Convert xe_bo_create_pin_map() for exhaustive eviction") Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://lore.kernel.org/r/20250910160939.103473-1-thomas.hellstrom@linux.intel.com
2025-10-10gpio: wcd934x: mark the GPIO controller as sleepingBartosz Golaszewski
The slimbus regmap passed to the GPIO driver down from MFD does not use fast_io. This means a mutex is used for locking and thus this GPIO chip must not be used in atomic context. Change the can_sleep switch in struct gpio_chip to true. Fixes: 59c324683400 ("gpio: wcd934x: Add support to wcd934x gpio controller") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-10-10drm/gud: Use kmalloc_array() instead of kmalloc()Mehdi Ben Hadj Khelifa
Replace kmalloc with kmalloc array in drm/gud/gud_pipe.c since the calculation inside kmalloc is dynamic 'width * height' Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com> Acked-by: Ruben Wauters <rubenru09@aol.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20251007083320.29018-1-mehdi.benhadjkhelifa@gmail.com
2025-10-10dpll: zl3073x: Increase maximum size of flash utilityIvan Vecera
Newer firmware bundles contain a flash utility whose size exceeds the currently allowed limit. Increase the maximum allowed size to accommodate the newer utility version. Without this patch: # devlink dev flash i2c/1-0070 file fw_nosplit_v3.hex Failed to load firmware Flashing failed Error: zl3073x: FW load failed: [utility] component is too big (11000 bytes) Fixes: ca017409da694 ("dpll: zl3073x: Add firmware loading functionality") Suggested-by: Prathosh Satish <Prathosh.Satish@microchip.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20251008141418.841053-1-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-10tpm: Prevent local DOS via tpm/tpm0/ppi/*operationsDenis Aleksandrov
Reads on tpm/tpm0/ppi/*operations can become very long on misconfigured systems. Reading the TPM is a blocking operation, thus a user could effectively trigger a DOS. Resolve this by caching the results and avoiding the blocking operations after the first read. [ jarkko: fixed atomic sleep: sed -i 's/spin_/mutex_/g' drivers/char/tpm/tpm_ppi.c sed -i 's/DEFINE_SPINLOCK/DEFINE_MUTEX/g' drivers/char/tpm/tpm_ppi.c ] Signed-off-by: Denis Aleksandrov <daleksan@redhat.com> Reported-by: Jan Stancek <jstancek@redhat.com> Closes: https://lore.kernel.org/linux-integrity/20250915210829.6661-1-daleksan@redhat.com/T/#u Suggested-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-10tpm: use a map for tpm2_calc_ordinal_duration()Jarkko Sakkinen
The current shenanigans for duration calculation introduce too much complexity for a trivial problem, and further the code is hard to patch and maintain. Address these issues with a flat look-up table, which is easy to understand and patch. If leaf driver specific patching is required in future, it is easy enough to make a copy of this table during driver initialization and add the chip parameter back. 'chip->duration' is retained for TPM 1.x. As the first entry for this new behavior address TCG spec update mentioned in this issue: https://github.com/raspberrypi/linux/issues/7054 Therefore, for TPM_SelfTest the duration is set to 3000 ms. This does not categorize a as bug, given that this is introduced to the spec after the feature was originally made. Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-10tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_singleGunnar Kudrjavets
The tpm_tis_write8() call specifies arguments in wrong order. Should be (data, addr, value) not (data, value, addr). The initial correct order was changed during the major refactoring when the code was split. Fixes: 41a5e1cf1fe1 ("tpm/tpm_tis: Split tpm_tis driver into a core and TCG TIS compliant phy") Signed-off-by: Gunnar Kudrjavets <gunnarku@amazon.com> Reviewed-by: Justinien Bouron <jbouron@amazon.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-10tpm: Use HMAC-SHA256 library instead of open-coded HMACEric Biggers
Now that there are easy-to-use HMAC-SHA256 library functions, use these in tpm2-sessions.c instead of open-coding the HMAC algorithm. Note that the new implementation correctly handles keys longer than 64 bytes (SHA256_BLOCK_SIZE), whereas the old implementation handled such keys incorrectly. But it doesn't appear that such keys were being used. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-10tpm: Compare HMAC values in constant timeEric Biggers
In tpm_buf_check_hmac_response(), compare the HMAC values in constant time using crypto_memneq() instead of in variable time using memcmp(). This is worthwhile to follow best practices and to be consistent with MAC comparisons elsewhere in the kernel. However, in this driver the side channel seems to have been benign: the HMAC input data is guaranteed to always be unique, which makes the usual MAC forgery via timing side channel not possible. Specifically, the HMAC input data in tpm_buf_check_hmac_response() includes the "our_nonce" field, which was generated by the kernel earlier, remains under the control of the kernel, and is unique for each call to tpm_buf_check_hmac_response(). Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-10tpm: Disable TPM2_TCG_HMAC by defaultJarkko Sakkinen
After reading all the feedback, right now disabling the TPM2_TCG_HMAC is the right call. Other views discussed: A. Having a kernel command-line parameter or refining the feature otherwise. This goes to the area of improvements. E.g., one example is my own idea where the null key specific code would be replaced with a persistent handle parameter (which can be *unambigously* defined as part of attestation process when done correctly). B. Removing the code. I don't buy this because that is same as saying that HMAC encryption cannot work at all (if really nitpicking) in any form. Also I disagree on the view that the feature could not be refined to something more reasoable. Also, both A and B are worst options in terms of backporting. Thuss, this is the best possible choice. Cc: stable@vger.kernel.or # v6.10+ Fixes: d2add27cf2b8 ("tpm: Add NULL primary creation") Suggested-by: Chris Fenner <cfenn@google.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-09drm/xe: Move rebar to be done earlierLucas De Marchi
There may be cases in which the BAR0 also needs to move to accommodate the bigger BAR2. However if it's not released, the BAR2 resize fails. During the vram probe it can't be released as it's already in use by xe_mmio for early register access. Add a new function in xe_vram and let xe_pci call it directly before even early device probe. This allows the BAR2 to resize in cases BAR0 also needs to move, assuming there aren't other reasons to hold that move: [] xe 0000:03:00.0: vgaarb: deactivate vga console [] xe 0000:03:00.0: [drm] Attempting to resize bar from 8192MiB -> 16384MiB [] xe 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: releasing [] xe 0000:03:00.0: BAR 2 [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing [] pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing [] pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing [] pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned [] pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned [] xe 0000:03:00.0: BAR 2 [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned [] xe 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: assigned [] pcieport 0000:00:01.0: PCI bridge to [bus 01-04] [] pcieport 0000:00:01.0: bridge window [mem 0x83000000-0x840fffff] [] pcieport 0000:00:01.0: bridge window [mem 0x4000000000-0x44007fffff 64bit pref] [] pcieport 0000:01:00.0: PCI bridge to [bus 02-04] [] pcieport 0000:01:00.0: bridge window [mem 0x83000000-0x840fffff] [] pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref] [] pcieport 0000:02:01.0: PCI bridge to [bus 03] [] pcieport 0000:02:01.0: bridge window [mem 0x83000000-0x83ffffff] [] pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref] [] xe 0000:03:00.0: [drm] BAR2 resized to 16384M [] xe 0000:03:00.0: [drm:xe_pci_probe [xe]] BATTLEMAGE e221:0000 dgfx:1 gfx:Xe2_HPG (20.02) ... For BMG there are additional fix needed in the PCI side, but this helps getting it to a working resize. All the rebar logic is more pci-specific than xe-specific and can be done very early in the probe sequence. In future it would be good to move it out of xe_vram.c, but this refactor is left for later. Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Cc: stable@vger.kernel.org # 6.12+ Link: https://lore.kernel.org/intel-xe/fafda2a3-fc63-ce97-d22b-803f771a4d19@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20250918-xe-pci-rebar-2-v1-2-6c094702a074@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-10fbdev: Fix logic error in "offb" name matchFinn Thain
A regression was reported to me recently whereby /dev/fb0 had disappeared from a PowerBook G3 Series "Wallstreet". The problem shows up when the "video=ofonly" parameter is passed to the kernel, which is what the bootloader does when "no video driver" is selected. The cause of the problem is the "offb" string comparison, which got mangled when it got refactored. Fix it. Cc: stable@vger.kernel.org Fixes: 93604a5ade3a ("fbdev: Handle video= parameter in video/cmdline.c") Reported-and-tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@linux-m68k.org> Signed-off-by: Helge Deller <deller@gmx.de>
2025-10-09rtc: interface: Ensure alarm irq is enabled when UIE is enabledEsben Haabendal
When setting a normal alarm, user-space is responsible for using RTC_AIE_ON/RTC_AIE_OFF to control if alarm irq should be enabled. But when RTC_UIE_ON is used, interrupts must be enabled so that the requested irq events are generated. When RTC_UIE_OFF is used, alarm irq is disabled if there are no other alarms queued, so this commit brings symmetry to that. Signed-off-by: Esben Haabendal <esben@geanix.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-5-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-10-09rtc: tps6586x: Fix initial enable_irq/disable_irq balanceEsben Haabendal
Interrupts are automatically enabled when requested, so we need to initialize irq_en accordingly to avoid causing an unbalanced enable warning. Signed-off-by: Esben Haabendal <esben@geanix.com> Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-4-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-10-09rtc: cpcap: Fix initial enable_irq/disable_irq balanceEsben Haabendal
Interrupts are automatically enabled when requested, so we need to initialize alarm_enabled accordingly to avoid causing an unbalanced enable warning. Signed-off-by: Esben Haabendal <esben@geanix.com> Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-3-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-10-09rtc: isl12022: Fix initial enable_irq/disable_irq balanceEsben Haabendal
Interrupts are automatically enabled when requested, so we need to initialize irq_enabled accordingly to avoid causing an unbalanced enable warning. Fixes: c62d658e5253 ("rtc: isl12022: Add alarm support") Signed-off-by: Esben Haabendal <esben@geanix.com> Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-2-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-10-09rtc: interface: Fix long-standing race when setting alarmEsben Haabendal
As described in the old comment dating back to commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") from 2010, we have been living with a race window when setting alarm with an expiry in the near future (i.e. next second). With 1 second resolution, it can happen that the second ticks after the check for the timer having expired, but before the alarm is actually set. When this happen, no alarm IRQ is generated, at least not with some RTC chips (isl12022 is an example of this). With UIE RTC timer being implemented on top of alarm irq, being re-armed every second, UIE will occasionally fail to work, as an alarm irq lost due to this race will stop the re-arming loop. For now, I have limited the additional expiry check to only be done for alarms set to next seconds. I expect it should be good enough, although I don't know if we can now for sure that systems with loads could end up causing the same problems for alarms set 2 seconds or even longer in the future. I haven't been able to reproduce the problem with this check in place. Cc: stable@vger.kernel.org Signed-off-by: Esben Haabendal <esben@geanix.com> Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-1-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-10-10Merge tag 'amd-drm-next-6.18-2025-10-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.18-2025-10-09: amdgpu: - DC DCE6 fixes - GPU reset fixes - Secure diplay messaging cleanup - MES fix - GPUVM locking fixes - PMFW messaging cleanup - PCI US/DS switch handling fix - VCN queue reset fix - DC FPU handling fix - DCN 3.5 fix - DC mirroring fix amdkfd: - Fix kfd process ref leak - mmap write lock handling fix - Fix comments in IOCTL Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20251009162915.981503-1-alexander.deucher@amd.com
2025-10-09drm/xe: Don't allow evicting of BOs in same VM in array of VM bindsMatthew Brost
An array of VM binds can potentially evict other buffer objects (BOs) within the same VM under certain conditions, which may lead to NULL pointer dereferences later in the bind pipeline. To prevent this, clear the allow_res_evict flag in the xe_bo_validate call. v2: - Invert polarity of no_res_evict (Thomas) - Add comment in code explaining issue (Thomas) Cc: stable@vger.kernel.org Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6268 Fixes: 774b5fa509a9 ("drm/xe: Avoid evicting object of the same vm in none fault mode") Fixes: 77f2ef3f16f5 ("drm/xe: Lock all gpuva ops during VM bind IOCTL") Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/20251009110618.3481870-1-matthew.brost@intel.com
2025-10-09Merge tag 'net-6.18-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from netfilter. Current release - regressions: - mlx5: fix pre-2.40 binutils assembler error Current release - new code bugs: - net: psp: don't assume reply skbs will have a socket - eth: fbnic: fix missing programming of the default descriptor Previous releases - regressions: - page_pool: fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches - tcp: - take care of zero tp->window_clamp in tcp_set_rcvlowat() - don't call reqsk_fastopen_remove() in tcp_conn_request() - eth: - ice: release xa entry on adapter allocation failure - usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock Previous releases - always broken: - netfilter: validate objref and objrefmap expressions - sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce() - eth: - mlx4: prevent potential use after free in mlx4_en_do_uc_filter() - mlx5: prevent tunnel mode conflicts between FDB and NIC IPsec tables - ocelot: fix use-after-free caused by cyclic delayed work Misc: - add support for MediaTek PCIe 5G HP DRMR-H01" * tag 'net-6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (38 commits) net: airoha: Fix loopback mode configuration for GDM2 port selftests: drv-net: pp_alloc_fail: add necessary optoins to config selftests: drv-net: pp_alloc_fail: lower traffic expectations selftests: drv-net: fix linter warnings in pp_alloc_fail eth: fbnic: fix reporting of alloc_failed qstats selftests: drv-net: xdp: add test for interface level qstats selftests: drv-net: xdp: rename netnl to ethnl eth: fbnic: fix saving stats from XDP_TX rings on close eth: fbnic: fix accounting of XDP packets eth: fbnic: fix missing programming of the default descriptor selftests: netfilter: query conntrack state to check for port clash resolution selftests: netfilter: nft_fib.sh: fix spurious test failures bridge: br_vlan_fill_forward_path_pvid: use br_vlan_group_rcu() netfilter: nft_objref: validate objref and objrefmap expressions net: pse-pd: tps23881: Fix current measurement scaling net/mlx5: fix pre-2.40 binutils assembler error net/mlx5e: Do not fail PSP init on missing caps net/mlx5e: Prevent tunnel reformat when tunnel mode not allowed net/mlx5: Prevent tunnel mode conflicts between FDB and NIC IPsec tables net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock ...
2025-10-09drm/i915/wm: Use fb->modfier to check for tiled vs. untiledVille Syrjälä
There is no point in checking the bo fence tiling mode when we can just check the fb modifier instead. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-6-ville.syrjala@linux.intel.com
2025-10-09drm/i915/fb: Drop the 'fb' argument from intel_fb_bo_framebuffer_init()Ville Syrjälä
intel_fb_bo_framebuffer_init() doesn't do anything with the passed framebuffer. Don't pass it therefore. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-5-ville.syrjala@linux.intel.com
2025-10-09drm/i915/fbdev: Select linear modifier explicitlyVille Syrjälä
Currently we use the implicit modifier fb creation path for fbdev, but as we never call set_tiling on the bo it will always end up as linear anyway. The rest of the code (eg. stride alignment) also assumes that we'll use linear. Just select the linear modifier explicitly. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-4-ville.syrjala@linux.intel.com
2025-10-09drm/i915/fb: Fix the set_tiling vs. addfb race, againVille Syrjälä
intel_frontbuffer_get() is what locks out subsequent set_tiling changes to the bo. Thus the fence vs. modifier check must be done after intel_frontbuffer_get(), or else a concurrent set_tiling ioctl might sneak in and change the fence after the check has been done. Close the race again. See commit dd689287b977 ("drm/i915: Prevent concurrent tiling/framebuffer modifications") for the previous instance. v2: Reorder intel_user_framebuffer_destroy() to match the unwind (Jani) Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Fixes: 10690b8a49bc ("drm/i915/display: Add intel_fb_bo_framebuffer_fini") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-3-ville.syrjala@linux.intel.com
2025-10-09drm/i915/frontbuffer: Move bo refcounting intel_frontbuffer_{get,release}()Ville Syrjälä
Currently xe's intel_frontbuffer implementation forgets to hold a reference on the bo. This makes the entire thing extremely fragile as the cleanup order now depends on bo references held by other things (namely intel_fb_bo_framebuffer_fini()). Move the bo refcounting to intel_frontbuffer_{get,release}() so that both i915 and xe do this the same way. I first tried to fix this by having xe do the refcounting from its intel_bo_set_frontbuffer() implementation (which is what i915 does currently), but turns out xe's drm_gem_object_free() can sleep and thus drm_gem_object_put() isn't safe to call while we hold fb_tracking.lock. Fixes: 10690b8a49bc ("drm/i915/display: Add intel_fb_bo_framebuffer_fini") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-10-09Merge tag 's390-6.18-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull more s390 updates from Alexander Gordeev: - Compile the decompressor with -Wno-pointer-sign flag to avoid a clang warning - Fix incomplete conversion to flag output macros in __xsch(), to avoid always zero return value instead of the expected condition code - Remove superfluous newlines from inline assemblies to improve compiler inlining decisions - Expose firmware provided UID Checking state in sysfs regardless of the device presence or state - CIO does not unregister subchannels when the attached device is invalid or unavailable. Update the purge function to remove I/O subchannels if the device number is found on cio_ignore list - Consolidate PAI crypto allocation and cleanup paths - The uv_get_secret_metadata() function has been removed some few months ago, remove also the function mention it in a comment * tag 's390-6.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/uv: Fix comment of uv_find_secret() function s390/pai_crypto: Consolidate PAI crypto allocation and cleanup paths s390/cio: Update purge function to unregister the unused subchannels s390/pci: Expose firmware provided UID Checking state in sysfs s390: Remove superfluous newlines from inline assemblies s390/cio/ioasm: Fix __xsch() condition code handling s390: Add -Wno-pointer-sign to KBUILD_CFLAGS_DECOMPRESSOR
2025-10-09nvme-multipath: Skip nr_active increments in RETRY dispositionAmit Chaudhary
For queue-depth I/O policy, this patch fixes unbalanced I/Os across nvme multipaths. Issue Description: The RETRY disposition incorrectly increments ns->ctrl->nr_active counter and reinitializes iostat start-time. In such cases nr_active counter never goes back to zero until that path disconnects and reconnects. Such a path is not chosen for new I/Os if multiple RETRY cases on a given a path cause its queue-depth counter to be artificially higher compared to other paths. This leads to unbalanced I/Os across paths. The patch skips incrementing nr_active if NVME_MPATH_CNT_ACTIVE is already set. And it skips restarting io stats if NVME_MPATH_IO_STATS is already set. base-commit: e989a3da2d371a4b6597ee8dee5c72e407b4db7a Fixes: d4d957b53d91eeb ("nvme-multipath: support io stats on the mpath device") Signed-off-by: Amit Chaudhary <achaudhary@purestorage.com> Reviewed-by: Randy Jennings <randyj@purestorage.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2025-10-09drm/panfrost: Name scheduler queues after their job slotsAdrián Larumbe
Drawing from commit d2624d90a0b7 ("drm/panthor: assign unique names to queues"), give scheduler queues proper names that reflect the function of their JM slot, so that this will be shown when gathering DRM scheduler tracepoints. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20251009114313.1374948-1-adrian.larumbe@collabora.com
2025-10-09drm/xe: Increase global invalidation timeout to 1000usKenneth Graunke
The previous timeout of 500us seems to be too small; panning the map in the Roll20 VTT in Firefox on a KDE/Wayland desktop reliably triggered timeouts within a few seconds of usage, causing the monitor to freeze and the following to be printed to dmesg: [Jul30 13:44] xe 0000:03:00.0: [drm] *ERROR* GT0: Global invalidation timeout [Jul30 13:48] xe 0000:03:00.0: [drm] *ERROR* [CRTC:82:pipe A] flip_done timed out I haven't hit a single timeout since increasing it to 1000us even after several multi-hour testing sessions. Fixes: 0dd2dd0182bc ("drm/xe: Move DSB l2 flush to a more sensible place") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5710 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://lore.kernel.org/r/20250912223254.147940-1-kenneth@whitecape.org Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-09drm: Prevent sign extension on hdisplay and vdisplayJonathan Cavitt
Some functions in drm multiply hdisplay and vdisplay with a third factor, which can result in a sign extension according to static analysis due to an implicit s32 promotion. Use a cast to u32 to prevent this. Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Krzystof Karas <krzysztof.karas@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Link: https://lore.kernel.org/r/20251007153645.90920-2-jonathan.cavitt@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-09drm/i915/display: Make intel_crtc_get_vblank_counter safe on PREEMPT_RTMaarten Lankhorst
drm_crtc_accurate_vblank_count takes a spinlock, which we should avoid in tracepoints and debug functions. This also prevents taking the spinlock 2x during the critical section of pipe updates for DSI updates. Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250829131701.15607-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-10-09drm/i915: Disable tracepoints for PREEMPT_RTMaarten Lankhorst
Luca Abeni reported this: | BUG: scheduling while atomic: kworker/u8:2/15203/0x00000003 | CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10 | Call Trace: | rt_spin_lock+0x3f/0x50 | gen6_read32+0x45/0x1d0 [i915] | g4x_get_vblank_counter+0x36/0x40 [i915] | trace_event_raw_event_i915_pipe_update_start+0x7d/0xf0 [i915] The tracing events use trace_intel_pipe_update_start() among other events use functions acquire spinlock_t locks which are transformed into sleeping locks on PREEMPT_RT. A few trace points use intel_get_crtc_scanline(), others use ->get_vblank_counter() wich also might acquire a sleeping locks on PREEMPT_RT. At the time the arguments are evaluated within trace point, preemption is disabled and so the locks must not be acquired on PREEMPT_RT. Based on this I don't see any other way than disable trace points on PREMPT_RT. [mlankhorst] The original patch was insufficient, and since the tracing infrastructure does not allow for partial disabling of tracepoints. Completely disable tracing for the entire i915 driver in PREEMPT_RT, a separate fix for display tracepoints on xe is added to make those work. Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reported-by: Luca Abeni <lucabe72@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Co-developed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250828090944.101069-1-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-10-09drm/panthor: skip regulator setup if no such propRain Yang
The regulator is optional, skip the setup instead of returning an error if it is not present Signed-off-by: Rain Yang <jiyu.yang@nxp.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250928090334.35389-2-jiyu.yang@oss.nxp.com
2025-10-09drm/panthor: Ensure MCU is disabled on suspendKetil Johnsen
Currently the Panthor driver needs the GPU to be powered down between suspend and resume. If this is not done, then the MCU_CONTROL register will be preserved as AUTO, which again will cause a premature FW boot on resume. The FW will go directly into fatal state in this case. This case needs to be handled as there is no guarantee that the GPU will be powered down after the suspend callback on all platforms. The fix is to call panthor_fw_stop() in "pre-reset" path to ensure the MCU_CONTROL register is cleared (set DISABLE). This matches well with the already existing call to panthor_fw_start() from the "post-reset" path. Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20251008105112.4077015-1-ketil.johnsen@arm.com
2025-10-09drm/xe/guc: Increase wait timeout to 2sec after BUSY reply from GuCSatyanarayana K V P
Some VF2GUC actions may take longer to process. Increase default timeout after received BUSY indication to 2sec to cover all worst case scenarios. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-35-matthew.brost@intel.com
2025-10-09drm/xe/vf: Rebase CCS save/restore BB GGTT addressesMatthew Brost
Rebase the CCS save/restore BB's GGTT addresses during VF post-migration recovery by setting the software ring tail to zero, the LRC ring head to zero, and rewriting the jump-to-BB instructions. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-34-matthew.brost@intel.com
2025-10-09drm/xe/vf: Ensure media GT VF recovery runs after primary GT on PTLMatthew Brost
It is possible that the media GT's VF post-migration recovery work item gets scheduled before the primary GT's work item. Since the media GT depends on the primary GT's work item to complete CCS restore, if the media GT's work item is scheduled first, detect this condition and re-queue the media GT's work item for a later time. v5: - Adjust debug message (Tomasz) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-33-matthew.brost@intel.com
2025-10-09drm/xe/vf: Use primary GT ordered work queue on media GT on PTL VFMatthew Brost
VF CCS restore is a primary GT operation on which the media GT depends. Therefore, it doesn't make much sense to run these operations in parallel. To address this, point the media GT's ordered work queue to the primary GT's ordered work queue on platforms that require (PTL VFs) CCS restore as part of VF post-migration recovery. v7: - Remove bool from xe_gt_alloc (Lucas) v9: - Fix typo (Lucas) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-32-matthew.brost@intel.com
2025-10-09drm/xe: Use PPGTT addresses for TLB invalidation to avoid GGTT fixupsSatyanarayana K V P
The migrate VM builds the CCS metadata save/restore batch buffer (BB) in advance and retains it so the GuC can submit it directly when saving a VM’s state. When a VM migrates between VFs, the GGTT base can change. Any GGTT-based addresses embedded in the BB would then have to be parsed and patched. Use PPGTT addresses in the BB (including for TLB invalidation) so the BB remains GGTT-agnostic and requires no address fixups during migration. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-31-matthew.brost@intel.com
2025-10-09drm/xe/vf: Workaround for race condition in GuC firmware during VF pauseMatthew Brost
A race condition exists where a paused VF's H2G request can be processed and subsequently rejected. This rejection results in a FAST_REQ failure being delivered to the KMD, which then terminates the CT via a dead worker and triggers a GT reset—an undesirable outcome. This workaround mitigates the issue by checking if a VF post-migration recovery is in progress and aborting these adverse actions accordingly. The GuC firmware will address this bug in an upcoming release. Once that version is available and VF migration depends on it, this workaround can be safely removed. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-30-matthew.brost@intel.com
2025-10-09drm/xe/vf: Add debug prints for GuC replaying state during VF recoveryMatthew Brost
Helpful to manually verify the GuC state machine can correctly replay the state during a VF post-migration recovery. All replay paths have been manually verified as triggered and working during testing. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-29-matthew.brost@intel.com
2025-10-09drm/xe: Move queue init before LRC creationMatthew Brost
A queue must be in the submission backend's tracking state before the LRC is created to avoid a race condition where the LRC's GGTT addresses are not properly fixed up during VF post-migration recovery. Move the queue initialization—which adds the queue to the submission backend's tracking state—before LRC creation. Also wait on pending GGTT fixups before allocating LRCs to avoid racing with fixups. v2: - Wait on VF GGTT fixes before creating LRC (testing) v5: - Adjust comment in code (Tomasz) - Reduce race window v7: - Only wakeup waiters in recovery path (CI) - Wakeup waiters on abort - Use GT warn on (Michal) - Fix kernel doc for LRC ring size function (Tomasz) v8: - Guard against migration not supported or no memirq (CI) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-28-matthew.brost@intel.com
2025-10-09drm/xe/vf: Replay GuC submission state on pause / unpauseMatthew Brost
Fixup GuC submission pause / unpause functions to properly replay any possible state lost during VF post migration recovery. v3: - Add helpers for revert / replay (Tomasz) - Add comment around WQ NOPs (Tomasz) v7: - Only fixup / replay parallel queues once (Testing) - Skip unpause step on queues created after resfix done (Testing) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-27-matthew.brost@intel.com
2025-10-09drm/xe/vf: Abort VF post migration recovery on failureMatthew Brost
If VF post-migration recovery fails, the device is wedged. However, submission queues still need to be enabled for proper cleanup. In such cases, call into the GuC submission backend to restart all queues that were previously paused. v3: - s/Avort/Abort (Tomasz) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-26-matthew.brost@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-04 10:09:03 +0000