summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-07-09drm/gpusvm: embed struct drm_device into drm_gpusvm_pagesHonglei Huang
drm_gpusvm_pages is the layer that actually represents physical pages/mappings it owns the dma_addr array, the dma_iova_state... With the previous patch, so drm_gpusvm_pages is now strictly about physical pages and their DMA view. Since now the drm_gpusvm_pages instance is inherently bound to one specific drm_device, make that ownership explicit by giving drm_gpusvm_pages its own drm_device handle, and drive all DMA through it instead of through the gpusvm: - Add drm to struct drm_gpusvm_pages and route all DMA in drm_gpusvm_get_pages() / __drm_gpusvm_unmap_pages() through svm_pages->drm instead of gpusvm->drm. - Bind svm_pages->drm where the pages object is initialised (drm_gpusvm_range_alloc() and the xe userptr setup) and require it to be set on entry to drm_gpusvm_get_pages(); the dma device is immutable for the lifetime of the pages instance. A later patch introduces drm_gpusvm_init_pages() to centralise this. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630102127.392396-3-honghuan@amd.com
2026-07-09drm/gpusvm: split MM state flags out of drm_gpusvm_pages_flagsHonglei Huang
drm_gpusvm_pages_flags currently mixes two status: - MM / virtual-address state: whether the range has been (partially) unmapped by the Linux MM, these follow the lifetime of the VMA and are a single per VA range fact. - Device mapping state: has_devmem_pages and has_dma_mapping, which describe the current page mapping status held by device itself. Keeping both on the pages object blurs the semantics of the abstraction of pages and VA range. So move the MM state flags onto the range, and keep drm_gpusvm_pages_flags strictly for mapping state. - Introduce drm_gpusvm_range_flags { migrate_devmem, unmapped, partial_unmap } on drm_gpusvm_range. - Shrink drm_gpusvm_pages_flags to just has_devmem_pages and has_dma_mapping. Side effect: drivers now need to check the unmap flags in the driver itself to avoid handling the unmapped pages. Mirror that bit onto drm_gpusvm_pages so the framework can still short circuit drm_gpusvm_get_pages() under the notifier lock, and make drm_gpusvm_range_set_unmapped() propagate it to the backing pages. This follows Matt's review fixup for the v0 series; see the Link below. Like drm_gpusvm_pages_flags, drm_gpusvm_range_flags unions its bits with a u16 __flags member. Build the new value in a local copy and publish it with a single WRITE_ONCE() on __flags, and have the lockless readers use READ_ONCE(), so concurrent bitfield access stays data-race free and KCSAN quiet. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://gitlab.freedesktop.org/mbrost/xe-kernel-driver-svn-perf-6-15-2025/-/commit/623f6a50c037d9e44f6c9fbe6859a0ba7ad50177 Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630102127.392396-2-honghuan@amd.com
2026-07-09macsec: don't read an unset MAC header in macsec_encrypt()Daehyeon Ko
macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d ("macvlan: do not assume mac_header is set in macvlan_broadcast()") for exactly this purpose. Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20260703083634.2035145-1-4ncienth@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09dibs: loopback: validate offset and size in move_data()Dust Li
The loopback move_data() performs a memcpy into the registered DMB without checking whether offset + size exceeds the DMB length. Unlike real ISM hardware, which enforces memory region bounds natively, the software loopback has no such protection. A peer-supplied out-of-bounds offset or oversized write would result in an OOB write past the allocated kernel buffer. Add an explicit bounds check before the memcpy to reject such requests with -EINVAL. Fixes: f7a22071dbf3 ("net/smc: implement DMB-related operations of loopback-ism") Cc: stable@vger.kernel.org Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com> Signed-off-by: Dust Li <dust.li@linux.alibaba.com> Reported-by: Baul Lee <baul.lee@xbow.com> Link: https://patch.msgid.link/20260707074318.1448662-1-dust.li@linux.alibaba.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09net : bonding : Remove TODO comment about retrying setting the MACParitosh Potukuchi
As correctly pointed out by Jay Vosburgh, "This comment dates to sometime before git, when it was common for network device drivers to lack the ability to change the MAC while the interface is up. To the best of my knowledge, that isn't a issue today." Based on the discussion in the RFC linked below, I am removing the TODO. Link to the RFC: https://lore.kernel.org/netdev/2001256.1782860341@famine/T/#t Signed-off-by: Paritosh Potukuchi <paritosh.potukuchi@amd.com> Link: https://patch.msgid.link/20260703125513.694324-1-paritosh.potukuchi@amd.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=nShuicheng Lin
When CONFIG_DRM_GPUSVM=n (e.g. um-allyesconfig), the only caller of xe_pt_svm_userptr_notifier_lock() is compiled out, triggering: drivers/gpu/drm/xe/xe_pt.c:1418:13: warning: 'xe_pt_svm_userptr_notifier_lock' defined but not used [-Wunused-function] The helpers cannot simply be removed in this case: the matching xe_pt_svm_userptr_notifier_unlock() is also referenced from xe_pt_update_ops_run(), which lives outside any DRM_GPUSVM ifdef and is gated only at runtime by pt_update_ops->needs_svm_lock. The symbol must exist in all builds. Provide empty static inline stubs for !DRM_GPUSVM, matching the pattern used by xe_svm_notifier_lock()/_unlock() in xe_svm.h. Fixes: dca6e08c923a ("drm/xe/userptr: Hold notifier_lock for write on inject test path") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606302210.QqcLbOEN-lkp@intel.com/ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630192221.2998168-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> (cherry picked from commit 3359422bf0a1140e96d783a19a397686e580a3ca) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-09drm/xe: free madvise VMA array on L2 flush failureGuangshuo Li
xe_vm_madvise_ioctl() allocates madvise_range.vmas in get_vmas(). After get_vmas() succeeds with at least one VMA, error paths must go through free_vmas so the array is released before the madvise details are destroyed. The L2 flush validation path added for PAT madvise rejects some SVM/userptr ranges after get_vmas() has succeeded, but jumps directly to madv_fini. This skips kfree(madvise_range.vmas), leaking the VMA array on each failed ioctl. Jump to free_vmas instead, matching the other validation failure paths after get_vmas() has succeeded. Fixes: 4f39a194d41e ("drm/xe/xe3p_lpg: Restrict UAPI to enable L2 flush optimization") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260708073422.725186-1-lgs201920130244@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit c3a1c3579b1250060da73507a4acef712974c78a) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-09drm/xe: remove duplicate <kunit/test-bug.h> includeAnas Khan
xe_pci.c includes <kunit/test-bug.h> twice, separated only by the <kunit/test.h> include. Drop the redundant second include; this is a non-functional cleanup flagged by scripts/checkincludes.pl. Fixes: 6cad22853cb8 ("drm/xe/kunit: Add stub to read_gmdid") Signed-off-by: Anas Khan <anxkhn28@gmail.com> Link: https://patch.msgid.link/20260702112820.34675-1-anxkhn28@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 84ed5b0a925721aaf069d36e18a99db966ff4e80) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-09drm/xe: Wait on external BO kernel fences in exec IOCTLMatthew Brost
Before arming a user job, xe_exec_ioctl() only added the VM's dma-resv KERNEL slot as a dependency. That slot covers rebinds and the kernel operations of the VM's private BOs, but not external BOs (bo->vm == NULL), which carry their kernel operations (evictions, moves, ...) in their own dma-resv KERNEL slot. The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for memory management operations that must complete before the BO or its backing store may be used: any accessor is required to wait on the KERNEL fences before touching the resv. By skipping the external BOs' KERNEL slots, the exec path violated that contract and could schedule a user job while a kernel operation on an external BO mapped by the VM was still in flight, racing against it and potentially reading or writing memory that was being moved. Replace the VM-only dependency with an iteration over every object locked by the exec, adding each object's KERNEL slot as a job dependency. This covers the VM resv (rebinds and private BOs) as well as every external BO, mirroring the drm_gpuvm_resv_add_fence() call that later publishes the job fence to the same set of objects. Long-running mode continues to skip this, as before. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260702215805.4011228-1-matthew.brost@intel.com (cherry picked from commit a6b842acf3ddd1efc53a56de9260cfa718fb35e7) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-09drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked bindsMatthew Brost
xe_vm_populate_pgtable() indexed the source PTE array (update->pt_entries) by the per-call loop counter, assuming each call starts at the first entry of the update. That holds for the CPU bind path (xe_migrate_update_pgtables_cpu), which populates a whole update in a single call, but not for the GPU bind path: write_pgtable() splits an update into MAX_PTE_PER_SDI (510) sized MI_STORE_DATA_IMM chunks, invoking the populate callback once per chunk with an advancing qword_ofs but a fresh command- buffer destination pointer. As a result, every chunk after the first re-read pt_entries from index 0 instead of from its true offset, so PTEs beyond the first 510 entries of a single update were programmed with the wrong physical pages, shifting the mapping by exactly MAX_PTE_PER_SDI pages. This stayed latent because a single update only exceeds 510 qwords when a large (e.g. 2M) region is bound as individual 4K PTEs rather than a single huge-page entry, which happens when the backing store is sufficiently fragmented. It was surfaced by the BO defrag path, which deliberately rebinds such fragmented ranges via the GPU bind path, producing deterministic data corruption offset by 510 pages. Index pt_entries by the chunk's absolute offset relative to update->ofs so both the CPU and GPU paths pick the correct entries. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260702012434.3861171-1-matthew.brost@intel.com (cherry picked from commit e6f2d0b757c4fb577a513c577140109d1d292a9a) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-09octeontx2-af: fix VF bringup affecting PF promiscuous stateHarman Kalra
Mbox handling of nix_set_rx_mode for a VF with promiscuous and all_multi flags set to false causes deletion of the PF's promiscuous and allmulti MCAM rules. This occurs because the APIs that enable/disable these rules operate only on the PF, even when the mbox request is made via a VF interface. Guard both rvu_npc_enable_allmulti_entry() and rvu_npc_enable_promisc_entry() disable paths with an is_vf() check so that a VF bringing up or tearing down its interface cannot inadvertently clear the PF's MCAM rules. Fixes: 967db3529eca ("octeontx2-af: add support for multicast/promisc packet replication feature") Signed-off-by: Harman Kalra <hkalra@marvell.com> Signed-off-by: Nitin Shetty J <nshettyj@marvell.com> Link: https://patch.msgid.link/20260702045616.3002773-2-nshettyj@marvell.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09leds: st1202: Validate LED reg property against channel countManuel Fombuena
The reg property from the device tree is used directly as an array index into chip->leds[] without bounds checking. A value >= ST1202_MAX_LEDS would cause an out-of-bounds write during probe. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena <fombuena@outlook.com> Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB849718B43321DB7E5A05D17BC5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09leds: st1202: Disable channel when brightness is set to zeroManuel Fombuena
When brightness_set() is called with LED_OFF, only the ILED register is zeroed; the channel enable bit is left set from probe time. A hardware channel enabled with ILED=0 still draws a small residual current, causing a dim glow even when the LED is supposed to be off. Fix this by splitting st1202_channel_set() into a lockless inner function __st1202_channel_set() and a locking wrapper, then calling the inner function from brightness_set() while it already holds the mutex. The channel is now disabled when value is zero and re-enabled when non-zero, in the same lock region as the ILED write. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena <fombuena@outlook.com> Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB8497F11B30FE7D74CAA25135C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09leds: st1202: Fix brightness having no effect while pattern mode is activeManuel Fombuena
Once a hardware pattern is running (PATS=1), writing to the brightness sysfs attribute only updates the ILED register. The visible output is ILED x Pattern_PWM / 4095, so the change has little effect and the LED never returns to steady static operation as the user expects. The LED1202 has a single global sequencer shared across all channels. Stopping it in brightness_set() to force static mode would halt running patterns on all other active LEDs. Instead, set all 8 PWM slots for the channel to ST1202_PATTERN_PWM_FULL before writing ILED. With every step at full duty cycle, the output is ILED x FULL / 4095 = ILED regardless of the sequencer state, without disturbing other channels. This also enables basic LED operation without the pattern trigger: with the trigger set to none, the brightness sysfs attribute fully controls the LED as a simple on/off device. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena <fombuena@outlook.com> Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB8497570FD162D0D42A9864E3C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09leds: st1202: Fix spurious pattern sequence start in setupManuel Fombuena
st1202_setup() writes PATS and PATSR to the Configuration register as its final step, which starts the hardware pattern sequencer during device probe before any patterns have been programmed. This causes the device to run a sequence with whatever values happen to be in the pattern registers at the time. Remove the write. The device reset at the start of setup restores all registers to their power-on defaults, leaving PATS and PATSR cleared. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena <fombuena@outlook.com> Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB849724B0FF00255F4760FAE0C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09leds: st1202: Set all pattern PWM slots to full after clearing patternManuel Fombuena
pattern_clear() sets all PWM registers for the channel to LED_OFF (0). In static mode (PATS=0), the LED output is ILED x Pattern0_PWM / 4095; with Pattern0 at zero the LED remains dark regardless of the ILED value. The LED1202 has a single global sequencer shared across all channels. If another channel starts the sequencer after this one has been cleared, the cleared channel runs through all 8 steps at zero duty cycle and stays dark regardless of ILED. Set all 8 PWM slots to ST1202_PATTERN_PWM_FULL so that ILED alone controls the channel brightness in both static and sequencer modes. Signed-off-by: Manuel Fombuena <fombuena@outlook.com> Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB849732C162CFE9E2C525AC16C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09leds: st1202: Fix pattern duration prescaler and pattern_clear skip markerManuel Fombuena
The PATy_DUR register encodes duration as N × 22.2 ms, with register value 0 reserved as a pattern skip indicator (§7.10). The driver incorrectly subtracted 1 from the register value: value / ST1202_MILLIS_PATTERN_DUR_MIN - 1 This caused two problems: - All programmed durations were off by one step (~22 ms too short). - Writing the minimum duration (22 ms) produced register value 0, silently skipping the pattern step instead of setting a 22 ms duration. The maximum duration constant was also wrong at 5660 ms. The 8-bit register saturates at 255, giving a maximum of 5610 ms (22 ms × 255). Values above 5653 ms were already producing a uint8_t overflow and writing 0 to the hardware. Fix the formula by removing the erroneous subtraction, and derive the maximum from the register width so the relationship is explicit. Update the documentation to reflect the correct maximum. This exposes a secondary issue: pattern_clear() was calling st1202_duration_pattern_write() with ST1202_MILLIS_PATTERN_DUR_MIN to reset unused slots, accidentally relying on the broken formula to produce register value 0. With the corrected formula, the same call writes 0x01 (22 ms), leaving unused slots as valid 22 ms zero-PWM steps and making the LED appear off for 7 × 22 ms out of every cycle. Write 0 directly to the duration registers in pattern_clear() so unused slots are always explicitly marked as skip, independently of the conversion formula. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena <fombuena@outlook.com> Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB84971D3AF982F4F707A378F0C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09leds: st1202: Validate pattern input before stopping the sequenceManuel Fombuena
Input validation for pattern duration is performed inside the write loop, after the pattern sequence has already been stopped. If validation fails mid-loop the chip is left with the sequence stopped and partially written pattern data, with no recovery. Move all input validation before the mutex and before any hardware interaction, so an invalid input leaves the chip state unchanged. Signed-off-by: Manuel Fombuena <fombuena@outlook.com> Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB84975929B6ED7CDFBCEB7D76C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09leds: st1202: Stop pattern sequence before reprogrammingManuel Fombuena
The LED1202 datasheet (section 4.8) states that modifications to the Pattern Sequence Repetition register (PAT_REP) and pattern duration registers are only applied after the sequence has completed or been stopped. When the device is running in infinite loop mode (PAT_REP = 0xFF) the sequence never completes on its own, so these writes are silently ignored by the hardware. Neither pattern_clear() nor pattern_set() stop the running sequence before modifying pattern registers, causing any subsequent pattern reprogramming to have no effect when the previous pattern was set to infinite repeat. Fix this by clearing PATS in the Configuration register before touching any pattern registers in both functions, ensuring the hardware accepts the new values immediately. Note that the LED1202 has a single global pattern sequencer shared by all channels: PATS, PATSR, the duration registers, and PAT_REP are chip-wide. Stopping the sequencer in pattern_clear() therefore halts any pattern running on other channels. This is an inherent hardware constraint; pattern_set() restarts the sequencer when a new pattern is programmed. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena <fombuena@outlook.com> Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB84978D0F499774773C7DA1FCC5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09leds: pca9532: Fix inverted GPIO output polarityCosmo Chou
The pca9532_gpio_set_value() function incorrectly mapped the requested value to PCA9532_ON and PCA9532_OFF, inverting the GPIO output polarity. A requested logical high (val=1) incorrectly enabled the LED output driver, which on this open-drain device pulls the pin low, while a requested logical low (val=0) released the pin. Correct the mapping so that val=1 yields PCA9532_OFF (pin released / high-impedance) and val=0 yields PCA9532_ON (pin driven low). pca9532_gpio_direction_input() is also updated to pass val=1 to pca9532_gpio_set_value() to align with the corrected polarity mapping, ensuring the pin remains not driven when configured as an input. Fixes: 3c1ab50d0a31 ("drivers/leds/leds-pca9532.c: add gpio capability") Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260703014201.69829-1-chou.cosmo@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09net/mlx5: Fix L3 tunnel entropy refcount leakLi RongQing
mlx5_tun_entropy_refcount_inc() counts both VXLAN and L2-to-L3 tunnel reformat entries as entropy-enabling users. The matching decrement path only handled VXLAN, leaving L2-to-L3 tunnel entries counted after release. Handle MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL in mlx5_tun_entropy_refcount_dec() as well so the enabling entry refcount remains balanced. Fixes: f828ca6a2fb6 ("net/mlx5e: Add support for hw encapsulation of MPLS over UDP") Signed-off-by: Li RongQing <lirongqing@baidu.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260703141423.1723-1-lirongqing@baidu.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09RDMA/ionic: Remove duplicate IONIC_SPEC_HIGH definitionKamal Heib
The macro IONIC_SPEC_HIGH is defined twice - remove it. Signed-off-by: Kamal Heib <kheib@redhat.com> Link: https://patch.msgid.link/20260708210734.641411-1-kheib@redhat.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-09net: mana: Add Interrupt Moderation supportHaiyang Zhang
Add Static and Dynamic Interrupt Moderation (DIM) support for Rx and Tx. Update queue creation procedure with new data struct with the related settings. Add functions to collect stat for DIM, and workers to update DIM data and settings. Update ethtool handler to get/set the moderation settings from a user. To avoid detach/re-attach ops, ring DIM doorbell to change settings at run time. By default, adaptive-rx/tx (DIM) are enabled if supported by HW. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260702220123.815018-1-haiyangz@linux.microsoft.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09net: macb: drop in-flight Tx SKBs on closeThéo Lebrun
The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty. Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver") Cc: stable@vger.kernel.org Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Link: https://patch.msgid.link/20260702-macb-drop-tx-v4-1-1c833eebdbc8@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09net: mana: Sync page pool RX frags for CPUDexuan Cui
MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack. Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") Cc: stable@vger.kernel.org Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Dexuan Cui <decui@microsoft.com> Link: https://patch.msgid.link/20260702041237.617719-3-decui@microsoft.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09net: mana: Validate the packet length reported by the NICDexuan Cui
Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted. Cc: stable@vger.kernel.org Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Dexuan Cui <decui@microsoft.com> Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Link: https://patch.msgid.link/20260702041237.617719-2-decui@microsoft.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09iommu/amd: Dynamically verify Southbridge IOAPIC via PCI config spaceWei Wang
check_ioapic_information() verifies whether the BIOS has provided a valid device ID for the Southbridge (SB) IOAPIC in the IVRS table. Currently, if the SB IOAPIC entry in the IVRS table does not match a historically hardcoded device ID (00:14.0), interrupt remapping is forcibly disabled. This hardcoded expectation does not scale to newer architectures. For example, recent Hygon Gen 4 servers use 00:0b.0 for the SB IOAPIC, which originally caused the validation to fail and interrupt remapping to be disabled until this device ID was added upstream. Instead of maintaining per-vendor/per-generation hardcoded device IDs, dynamically verify the SB IOAPIC by reading its PCI configuration space. Because the SB IOAPIC is embedded within the FCH (Fusion Controller Hub) and shares its device ID, we can inspect the PCI class code of the given device ID to confirm it is an actual FCH device (a SMBus controller or ISA Bridge). Signed-off-by: Wei Wang <wei.w.wang@hotmail.com> Tested-by: Yongwei Xu <xuyongwei@open-hieco.net> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/amd: Fix false positive in SB IOAPIC IVRS validationWei Wang
The check_ioapic_information() function is designed to prevent boot hangs by ensuring the Southbridge (SB) IOAPIC is properly mapped in the IVRS table before enabling Interrupt Remapping. Currently, this check passes if *any* enumerated IOAPIC matches the expected SB IOAPIC device ID. If a buggy BIOS incorrectly assigns the SB IOAPIC's device ID to a secondary IOAPIC in the IVRS, while scrambling the true SB IOAPIC's mapping, the check hits a false positive and succeeds. This erroneously enables Interrupt Remapping. Consequently, the IOMMU blocks unmapped interrupts from the actual SB IOAPIC, dropping the system timer and leading to a silent kernel boot hang. Tighten the validation to verify the device ID specifically against the SB IOAPIC by matching their APIC IDs first. This prevents the validation check from being bypassed via device ID aliasing. Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table") Signed-off-by: Wei Wang <wei.w.wang@hotmail.com> Tested-by: Yongwei Xu <xuyongwei@open-hieco.net> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errorsWei Wang
The check_ioapic_information() function validates IOAPICs against the IVRS table to safely disable Interrupt Remapping (IR) if the BIOS provides a broken topology. Currently, the validation loop contains a bug: If an unmapped secondary IOAPIC is encountered, 'ret' is set to false. But if the Southbridge (SB) IOAPIC is enumerated after it in the MADT, the loop overwrites 'ret' to true. This bypasses the validation failure and leaves IR enabled. When devices attached to the unmapped secondary IOAPIC fire interrupts, the IOMMU drops them due to the missing Requestor ID, leading to localized device hangs. Fix this by initializing 'ret' to true and only toggling it to false upon encountering a validation error, ensuring failures are never erased. Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table") Signed-off-by: Wei Wang <wei.w.wang@hotmail.com> Tested-by: Yongwei Xu <xuyongwei@open-hieco.net> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/msm: Return -ENOMEM on memory allocation failure in probeVladimir Zapolskiy
If dynamic memory allocation in driver's probe function execution fails, it should be reported to the driver's framework with -ENOMEM error code. Fixes: 109bd48ea2e1 ("iommu/msm: Add DT adaptation") Signed-off-by: Vladimir Zapolskiy <vz@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/mediatek-v1: Fix off-by-one in MT2701_LARB_NR_MAXAkari Tsuyukusa
The mt2701_m4u_in_larb[] array contains 4 (for LARB0 to LARB3) elements, meaning mt2701_m4u_to_larb() can legitimately return 3. The current check `if (larbid >= MT2701_LARB_NR_MAX)` incorrectly rejects valid LARB3 with -EINVAL. Fix this off-by-one error by updating MT2701_LARB_NR_MAX to 4. Note that this does not cause immediate issues with the current mt2701.dtsi and mt7623n.dtsi because it only defines 3 LARBs: mediatek,larbs = <&larb0 &larb1 &larb2>; Thus, larbid never reaches 3 in the existing upstream device tree. Fixes: de78657e16f4 ("iommu/mediatek: Fix NULL pointer dereference when printing dev_name") Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/vt-d: Fail probe on ATS configuration failurePranjal Shrivastava
Update the Intel VT-d driver to handle ATS configuration and enablement more strictly. Specifically, update the device probe to fail if pci_prepare_ats() returns an error. This ensures that any ATS-capable master reaching the attach phase is guaranteed to have a valid config. Additionally, update iommu_enable_pci_ats() to WARN() if pci_enable_ats fails. Since earlier checks in the probe phase preclude config-related failures, any failure during hardware enablement is considered a kernel bug. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/arm-smmu-v3: Standardize ATS enablement failure reportingPranjal Shrivastava
Update arm_smmu_enable_ats() to wrap the pci_enable_ats() call in a WARN(). Since probe-time checks now preclude configuration errors any failure during hardware enablement is considered a kernel bug. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09PCI/ATS: Validate STU for VFs in pci_prepare_ats()Pranjal Shrivastava
While every PCI Function that implements ATS has an independent ATS Extended Capability structure with a Read/Write Smallest Translation Unit (STU) field, the kernel manages SR-IOV ATS by requiring the IOMMU driver to configure the STU on the Physical Function (PF) before any any Virtual Functions (VFs) are created. Currently, pci_prepare_ats() bails out early for VFs, assuming that the PF has already been correctly prepared. However, this creates a potential mismatch if a VF is subsequently prepared with a different page shift. Update pci_prepare_ats() to validate that the requested page shift (ps) matches the STU already configured in the associated PF. This ensures early detection of incompatible configurations and maintains the kernel's policy of consistent STU sizing across all functions associated with a given SMMU. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09PCI/ATS: Ensure pci_ats_supported() is PF-aware for VFsPranjal Shrivastava
Update pci_ats_supported() to additionally check the associated PF's status when called on a VF. This ensures that PF-level quirks and untrusted status are correctly propagated to VFs, providing a robust support check that aligns with the kernel's PF-centric ATS configuration model and is immune to the timing of VF-specific fixups. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/riscv: Drop superfluous zeros in pci_device_id arrayUwe Kleine-König (The Capable Hub)
The .driver_data member of the struct pci_device_id array were initialized by a list expressions to zero without making use of that value. In this case it's better to not specify a value at all and let the compiler fill in the zeros. Same for the list terminator that can better be completely empty. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09drm/i915/kunit: DP link: add fallback testsImre Deak
Add KUnit tests for DP link fallback selection across eDP, SST, and MST. Verify that the fallback logic properly selects the maximum allowed configuration, iterates through allowed configurations, and disables failed configs as expected. These tests include UHBR vs. non-UHBR conditions, MST vs. SST mode, and validate that subsequent fallback selections respect the updated allowed configuration mask. v2: - Rebase on changes using a filter object instead of a mask of configuration indices. - Rebase on changes using an iteration object. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-35-imre.deak@intel.com
2026-07-09drm/i915/kunit: DP link: add update config testsImre Deak
Add KUnit tests for link_caps updates shrinking or expanding the supported rates and lane counts. The tests also cover updates with disabled configurations, including random shrink and expand sequences, to verify that disabled state, allowed configurations, ordering, and max limits stay consistent across updates. v2: Remove test cases for the now unused merge update mode. v3: - Test config iteration in lane count, rate order as well. - Keep space after comma in code comment. (Michał) Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v2 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-4-imre.deak@intel.com
2026-07-09drm/i915/kunit: DP link: add baseline fixed table reference testImre Deak
Add a simple baseline test for DP link caps iteration using a fixed standard DP configuration table. This provides a minimal validity check, independent of more complex test setups, verifying the iterator returns expected configurations in ascending and descending order. v2: Unchanged. v3: Test config iteration in lane count, rate order as well. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v2 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-3-imre.deak@intel.com
2026-07-09drm/i915/kunit: Export link training and caps funcs for testingImre Deak
Export the link caps and link training helpers needed by the DP link KUnit tests. Use test ops tables instead of exporting the helpers directly, avoiding symbol name collisions between the i915 and xe builds of the shared display code. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-32-imre.deak@intel.com
2026-07-09drm/i915/kunit: Setup DP link test contextImre Deak
Initialize a reusable test context for DP link KUnit tests. Sets up minimal device, connector, encoder, and DP structures, and seeds the pseudo-random generator for deterministic test runs. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-31-imre.deak@intel.com
2026-07-09drm/xe/kunit: Build DP link display testsImre Deak
Hook the shared i915 display DP link KUnit tests into the xe display test build. Build the shared display test source from the i915 display test directory when xe display support is enabled. v2: Unchanged. v3: Add SPDX license header. (Michał) Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-2-imre.deak@intel.com
2026-07-09drm/xe/kunit: Add display test configImre Deak
Add a separate xe KUnit config for display tests. The existing xe .kunitconfig builds xe statically, which is suitable for non-display xe tests. The display code can only be enabled for xe when xe is built as a module, so add a separate display config with DRM_XE=m and DRM_XE_DISPLAY=y. This can be folded back into the main xe KUnit config once the display code becomes a separate module. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-29-imre.deak@intel.com
2026-07-09drm/i915/kunit: Add DP link test stubImre Deak
Add a Kunit stub test module for DP link test cases. v2: Add missing module license. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-28-imre.deak@intel.com
2026-07-09drm/i915/kunit: Enable KUnit testsImre Deak
Add KUnit configuration for i915 and a local .kunitconfig to run the tests. v2: Unchanged. v3: Remove kconfig options for kernel debug. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v2 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-1-imre.deak@intel.com
2026-07-09drm/i915/dp_link_training: Disable failed config during fallbackImre Deak
Disable the link configuration that failed training when selecting fallback parameters. Fallback still selects the next configuration using the existing fallback order, but now also removes the failed configuration from the allowed set. Functionally, this only affects the case where an MST <-> SST mode switch occurs on the same root connector: previously, a configuration that failed training in one mode could be reused in the other mode due to the differing config iteration orders. The current fallback logic also sets a temporary maximum link limit across the allowed configurations to constrain subsequent modesets. This legacy behavior is preserved for now; it will be removed once the fallback logic relies solely on the individually disabled configurations to restrict the allowed set. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-26-imre.deak@intel.com
2026-07-09drm/i915/dp_link_training: Use config iterator for fallbackImre Deak
Switch the fallback loop to use the link configuration iterator to select a fallback configuration. This also allows unexporting and removing from the link caps interface all the common link rate query helpers and the helpers that accept or return a link configuration index. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-25-imre.deak@intel.com
2026-07-09drm/i915/dp_link_training: Reset the max link limits in the fallback codeImre Deak
The target maximum rate/lane count selected by the fallback logic may exceed the current link_caps max_limits' rate/lane count, the latter of which are used as a limit by the lookup functions when filtering allowed configurations. To ensure the fallback search finds all relevant candidates, temporarily reset the link_caps max_limits to the maximum common supported capabilities. After the fallback search completes, set the link_caps max_limits to the configuration selected by the fallback logic, as before, determining the allowed configurations for a subsequent modeset. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-24-imre.deak@intel.com
2026-07-09drm/i915/dp: Remove min/max link config limitsImre Deak
Remove the min/max rate and lane count fields from struct link_config_limits after all state computation is converted to use the configuration filter. A simple min/max range cannot fully describe the valid configuration set once individual configurations are disabled (for example by fallback), as it may allow combinations that are not actually valid. The configuration filter, on the other hand, always represents a consistent set of valid configurations. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-23-imre.deak@intel.com
2026-07-09drm/i915/dp_mst: Use link caps for MST DSC config selectionImre Deak
Use the link caps helper to select the maximum DP MST link configuration for DSC computation, instead of using the separate max rate and lane count limits, which may not form a valid configuration after individual configs are disabled by fallback. Also look up the maximum rate for state computation via the configuration mask when checking the DSC hblank expansion quirk. This is a step towards unifying configuration selection and iteration across connector types and between compute and fallback paths. The state computation should likely consider all allowed configurations, as noted in the code comment; for now keep the existing DP MST DSC behavior of selecting the maximum BW configuration determined by the MST connector BW config iteration order. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-22-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-03 14:15:14 +0000