summaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorLines
2026-03-17drm/amdgpu/gmc12: Query host-gpu interfaceHawking Zhang-0/+4
Query host-gpu interconnect type for gmc v12 devices Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Retire get_xgmi_info callback for gfxhub v12_1Hawking Zhang-42/+0
gfxhub v12_1 is not always on. querying xgmi info from it may not work consistently Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Query xgmi info from mmhub if availableHawking Zhang-3/+15
Query xgmi info from mmhub if available Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Implement get_xgmi_info callback for mmhub_v4_2Hawking Zhang-0/+41
Query memory region assignment and address via mmhub Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu/gmc12: Update gmc aperture base for A + AHawking Zhang-2/+6
Query mmhub MC_VM_FB_OFFSET, XGMI_LFB_CNTL|SIZE registers to calculate gmc apeture base address for A + A configuration Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu/gmc12: Bypass FB resize on A + A platformHawking Zhang-1/+2
Resizing fb bar is not needed/supported on A + A platform. Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Update gfxhub system aperture settings for A + AHawking Zhang-64/+71
Bypass the programming from SRIOV guest Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Correct mmhub system aperture settings for A + AHawking Zhang-67/+68
Disable AGP and FB apeture on all available MMHUB instances when vmid0 page table is enabled Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu/gmc12: Set up pdb0 for vmid0 page tableHawking Zhang-1/+13
Alloc, Init and free pdb0 for vmid0 page table that is used for fb translation on A + A platform Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Init table depth and block_size for A + AHawking Zhang-0/+8
Initialize page table depth and page table block size for 2-level gart table construction on A + A platform Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Place gart and vram in sysvm aper for A + AHawking Zhang-6/+9
On A + A platform, sysvm aperture is used for both vram and gart access. In sysvm aperture, vram starts at 0, and gart starts right after vram. Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Limit physical transcation mode to A + A onlyHawking Zhang-4/+12
Only enable page table walker to snoop CPU cache on A + A platform Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Support forcing MTYPE_RWHarish Kasiviswanathan-14/+26
Set default value of module parameter amdgpu_mtype_local to -1. This allows to force MTYPE_RW on ASICs where MTYPE_RW is not default. v2: Fix SDMA get_vm_pte_pde MTYPE Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Update MTYPE for GFX12.1Harish Kasiviswanathan-19/+22
Update MTYPE for GFX12.1 for AID A0 and A1 Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Philip.Yang <Philip.Yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdkfd: Don't expect signal mailbox updateHarish Kasiviswanathan-21/+26
GFX12.1 CP to improve performance has removed updating event_id into signal mailbox. In future, this optimization can be extended to older ASICs. Update driver code to handle this case. Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: update cp packets for gfx v12_1Likun Gao-122/+101
Clean up some unsupport CP packets for gfx v12_1. Update CP packets for gfx v12_1 with some new definition. Signed-off-by: Likun Gao <Likun.Gao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: retire some unsupport cmd pkt bit for gfx v12_1Likun Gao-12/+5
Retire some unsupport CP command bit set for gfx v12_1. Signed-off-by: Likun Gao <Likun.Gao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: 57-bit enable for watch address on gfx_v12_1Alex Sierra-1/+1
Add 57-bit support for debugger set watch address API Signed-off-by: Alex Sierra <alex.sierra@amd.com> Co-authored-by: Alexey Kondratiev <Alexey.Kondratiev@amd.com> Reviewed-by: Philip.Yang <Philip.Yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu/mes12_1: fix the failure access to MID1 registersJack Xiao-38/+52
Correct the mid die id and mid1 register relative offset for mes fw to access to mid1 registers. Signed-off-by: Jack Xiao <Jack.Xiao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdkfd: Update queue properties for metadata ringPhilip Yang-1/+2
Metadata ring and queue ring is allocated as one buffer and map to GPU, so update queue peoperties should add the queue metadata size and ring size as buffer size to validate queue ring buffer. Fixes: c51bb53d5c68 ("drm/amdkfd: Add metadata ring buffer for compute") Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Alex Sierra <alex.sierra@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Revert setting up Retry based Thrashing on GFX 12.1Sreekant Somasekharan-19/+0
Bug found with retry based thrashing mechanism. Revert to the old thrashing method. Signed-off-by: Sreekant Somasekharan <Sreekant.Somasekharan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu: Fix RRMT for gfx v12_1Michael Chen-1/+1
Correct NORMALIZE_XCC_REG_OFFSET to 0xFFFF because reg offset is in DW. Also set mode 3 temporarily for out of XCD access for MMHUB TLB flush. Will need to figure out how to differentiate between AID and MID access later. Signed-off-by: Michael Chen <michael.chen@amd.com> Reviewed-by: Alex Sierra <alex.sierra@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17drm/amdgpu/mes_v12_1: add mes self testJack Xiao-1/+334
Add mes self test to ensure that mes user queue work. V2: add pasid on amdgpu_vm_init. V3: Squash in fix non-SPX modes (Mukul) Signed-off-by: Jack Xiao <Jack.Xiao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17Revert "drm/amdgpu: revert to old status lock handling v4"Sunil Khatri-68/+105
This reverts commit 7a9419ab42699fd3d4c857ef81ae097d8d8d5899. Reverting due to some of the probable issues caused by this change and CI is blocked. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17USB: serial: io_edgeport: add support for Blackbox IC135AFrej Drejhammar-0/+4
The Blackbox 724-746-5500 USB Director USB-RS-232 HUB, part number IC135A, is a rebadged Edgeport/4 with its own USB device id. Signed-off-by: Frej Drejhammar <frej@stacken.kth.se> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2026-03-17drm/imagination: Disable interrupts before suspending the GPUAlessio Belle-10/+23
This is an additional safety layer to ensure no accesses to the GPU registers can be made while it is powered off. While we can disable IRQ generation from GPU, META firmware, MIPS firmware and for safety events, we cannot do the same for the RISC-V firmware. To keep a unified approach, once the firmware has completed its power off sequence, disable IRQs for the while GPU at the kernel level instead. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260310-drain-irqs-before-suspend-v1-2-bf4f9ed68e75@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-03-17drm/imagination: Synchronize interrupts before suspending the GPUAlessio Belle-20/+8
The runtime PM suspend callback doesn't know whether the IRQ handler is in progress on a different CPU core and doesn't wait for it to finish. Depending on timing, the IRQ handler could be running while the GPU is suspended, leading to kernel crashes when trying to access GPU registers. See example signature below. In a power off sequence initiated by the runtime PM suspend callback, wait for any IRQ handlers in progress on other CPU cores to finish, by calling synchronize_irq(). At the same time, remove the runtime PM resume/put calls in the threaded IRQ handler. On top of not being the right approach to begin with, and being at the wrong place as they should have wrapped all GPU register accesses, the driver would hit a deadlock between synchronize_irq() being called from a runtime PM suspend callback, holding the device power lock, and the resume callback requiring the same. Example crash signature on a TI AM68 SK platform: [ 337.241218] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError [ 337.241239] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241246] Tainted: [M]=MACHINE_CHECK [ 337.241249] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241252] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 337.241256] pc : pvr_riscv_irq_pending+0xc/0x24 [ 337.241277] lr : pvr_device_irq_thread_handler+0x64/0x310 [ 337.241282] sp : ffff800085b0bd30 [ 337.241284] x29: ffff800085b0bd50 x28: ffff0008070d9eab x27: ffff800083a5ce10 [ 337.241291] x26: ffff000806e48f80 x25: ffff0008070d9eac x24: 0000000000000000 [ 337.241296] x23: ffff0008068e9bf0 x22: ffff0008068e9bd0 x21: ffff800085b0bd30 [ 337.241301] x20: ffff0008070d9e00 x19: ffff0008068e9000 x18: 0000000000000001 [ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40 [ 337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a [ 337.241314] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff800085b0bd00 [ 337.241318] x8 : ffff0008071175d0 x7 : 000000000000b955 x6 : 0000000000000003 [ 337.241323] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 0000000000000000 [ 337.241327] x2 : ffff800080e39d20 x1 : ffff800080e3fc48 x0 : 0000000000000000 [ 337.241333] Kernel panic - not syncing: Asynchronous SError Interrupt [ 337.241337] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241342] Tainted: [M]=MACHINE_CHECK [ 337.241343] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241345] Call trace: [ 337.241348] show_stack+0x18/0x24 (C) [ 337.241357] dump_stack_lvl+0x60/0x80 [ 337.241364] dump_stack+0x18/0x24 [ 337.241368] vpanic+0x124/0x2ec [ 337.241373] abort+0x0/0x4 [ 337.241377] add_taint+0x0/0xbc [ 337.241384] arm64_serror_panic+0x70/0x80 [ 337.241389] do_serror+0x3c/0x74 [ 337.241392] el1h_64_error_handler+0x30/0x48 [ 337.241400] el1h_64_error+0x6c/0x70 [ 337.241404] pvr_riscv_irq_pending+0xc/0x24 (P) [ 337.241410] irq_thread_fn+0x2c/0xb0 [ 337.241416] irq_thread+0x170/0x334 [ 337.241421] kthread+0x12c/0x210 [ 337.241428] ret_from_fork+0x10/0x20 [ 337.241434] SMP: stopping secondary CPUs [ 337.241451] Kernel Offset: disabled [ 337.241453] CPU features: 0x040000,02002800,20002001,0400421b [ 337.241456] Memory Limit: none [ 337.457921] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW support") Fixes: 96822d38ff57 ("drm/imagination: Handle Rogue safety event IRQs") Cc: stable@vger.kernel.org # see patch description, needs adjustments for < 6.16 Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260310-drain-irqs-before-suspend-v1-1-bf4f9ed68e75@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-03-17drm/imagination: Fix deadlock in soft reset sequenceAlessio Belle-1/+10
The soft reset sequence is currently executed from the threaded IRQ handler, hence it cannot call disable_irq() which internally waits for IRQ handlers, i.e. itself, to complete. Use disable_irq_nosync() during a soft reset instead. Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW support") Cc: stable@vger.kernel.org Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260309-fix-soft-reset-v1-1-121113be554f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-03-17drm/amd/display: Fix gamma 2.2 colorop TFsAlex Hung-3/+3
Use GAMMA22 for degamma/blend and GAMMA22_INV for shaper so curves match the color pipeline. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5016 Tested-by: Xaver Hugl <xaver.hugl@kde.org> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-17net: airoha: select QDMA block according LAN/WAN configurationLorenzo Bianconi-10/+9
Before this patch even GDM ports were assigned to QDMA0 while odd GDM ports were using QDMA1, so, based on the DTS configuration, both QDMA0 and QDMA1 can theoretically receive traffic destinated to the host cpu from LAN or WAN GDM ports. Airoha folks reported the hw design assumes the LAN traffic destinated to the host cpu is be forwarded to QDMA0 while traffic received on WAN GDM port is managed by QDMA1. For this reason, select QDMA block according to the GDM port LAN or WAN configuration: - QDMA0 is used for GDM LAN devices - QDMA1 is used for GDM WAN device Assuming a device with three GDM ports, a typical configuration could be: - MT7530 DSA switch -> GDM1 (eth0) -> QDMA0 (LAN traffic) - External PHY -> GDM2 (eth1) -> QDMA1 (WAN traffic) - External PHY -> GDM3 (eth2) -> QDMA0 (LAN traffic) We can then bridge eth0 DSA port (lanX) with eth2 since they all tx/rx LAN traffic. Please note this patch introduces a change not visible to the user since airoha_eth driver currently supports just the internal phy available via the MT7530 DSA switch and there are no WAN interfaces officially supported since PCS/external phy is not merged mainline yet (it will be posted with following patches). Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260313-airoha-qdma-lan-wan-mode-v2-1-7d577db6e40c@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-17USB: serial: option: add support for Rolling Wireless RW135R-GLWanquan Zhong-0/+1
Add VID/PID 33f8:1003 for the Rolling Wireless RW135R-GL M.2 module, which is used in laptop debug cards with MBIM interface for Linux/Chrome OS. The device supports mbim, pipe functionalities. Here are the outputs of usb-devices: T: Bus=04 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=33f8 ProdID=1003 Rev=05.15 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW135R-GL Module S: SerialNumber=12345678 C: #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms Signed-off-by: Wanquan Zhong <wanquan.zhong@fibocom.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2026-03-17media: lirc: increase IR_MAX_DURATION to send extended code sequencesLiPeng Huang-2/+2
sensor:increase IR_MAX_DURATION to 1000ms to fix long IR remote timeouts Certain infrared remotes (e.g., brand-specific smart home remotes, custom consumer electronics) send extended code sequences that exceed the default 500ms IR_MAX_DURATION threshold. This causes the kernel's raw IR driver to discard incomplete code, resulting in unrecognized commands. Increase IR_MAX_DURATION to 1000ms: - Aligns with common extended IR protocol specs (most long sequences use 700-900ms) - No impact on standard remotes (all mainstream IR codes are <500ms) - Validated on vivo X200 and vivo X300, resolves timeout issues without regressions Signed-off-by: LiPeng Huang <huanglipeng@vivo.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-17media: mceusb: drop redundant device referenceJohan Hovold-3/+1
Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. Drop the redundant device reference to reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of memory leaks when drivers fail to release it. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-17media: imon: drop redundant device referencesJohan Hovold-10/+3
Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. Drop the redundant device references to reduce cargo culting, make it easier to spot drivers where extra references are needed, and reduce the risk of memory leaks when drivers fail to release them. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-17media: rc: ttusbir: respect DMA coherency rulesOliver Neukum-4/+9
Buffers must not share a cache line with other data structures. Allocate separately. Fixes: 0938069fa0897 ("[media] rc: Add support for the TechnoTrend USB IR Receiver") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-17media: rc: igorplugusb: heed coherency rulesOliver Neukum-5/+11
In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately. Fixes: b1c97193c6437 ("[media] rc: port IgorPlug-USB to rc-core") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-17media: rc: xbox_remote: heed DMA restrictionsOliver Neukum-1/+8
The buffer for IO must not be part of the device structure because that violates the DMA coherency rules. Fixes: 02d32bdad3123 ("media: rc: add driver for Xbox DVD Movie Playback Kit") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-17media: rc: streamzap: Error handling in probeOliver Neukum-4/+8
If submitting the URB fails, the device will be unusable. Probe() must fail. Fixes: 7a569f524dd36 ("V4L/DVB: IR/streamzap: functional in-kernel decoding") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-17media: rc: fix race between unregister and urb/irq callbacksSean Young-34/+58
Some rc device drivers have a race condition between rc_unregister_device() and irq or urb callbacks. This is because rc_unregister_device() does two things, it marks the device as unregistered so no new commands can be issued and then it calls rc_free_device(). This means the driver has no chance to cancel any pending urb callbacks or interrupts after the device has been marked as unregistered. Those callbacks may access struct rc_dev or its members (e.g. struct ir_raw_event_ctrl), which have been freed by rc_free_device(). This change removes the implicit call to rc_free_device() from rc_unregister_device(). This means that device drivers can call rc_unregister_device() in their remove or disconnect function, then cancel all the urbs and interrupts before explicitly calling rc_free_device(). Note this is an alternative fix for an issue found by Haotian Zhang, see the Closes: tags. Reported-by: Haotian Zhang <vulab@iscas.ac.cn> Closes: https://lore.kernel.org/linux-media/20251114101432.2566-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114101418.2548-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114101346.2530-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114090605.2413-1-vulab@iscas.ac.cn/ Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-17platform/x86: thinkpad_acpi: Add sysfs control for TrackPoint double-tapVishnu Sankar-7/+35
Add a sysfs attribute to enable or disable TrackPoint double-tap hotkey events at the kernel level. The TrackPoint firmware enables double-tap support automatically. This interface allows userspace to control whether double-tap events are forwarded to userspace. The attribute is available at: /sys/devices/platform/thinkpad_acpi/doubletap_enable 0 - Disable double-tap hotkey events 1 - Enable double-tap hotkey events (default) Filtering is implemented by suppressing ACPI hotkey delivery without injecting synthetic input events. Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com> Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://patch.msgid.link/20260311143144.482145-3-vishnuocv@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-17input: trackpoint - Enable doubletap by default on capable devicesVishnu Sankar-0/+51
Enable doubletap functionality by default on TrackPoint devices that support it. The feature is detected using firmware ID pattern matching (PNP: LEN03xxx) with a deny list of incompatible devices. This provides immediate doubletap functionality without requiring userspace configuration. The hardware is enabled during device detection, while event filtering continues to be handled by the thinkpad_acpi driver as before. Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com> Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://patch.msgid.link/20260311143144.482145-2-vishnuocv@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-17iommufd: Report ATS not supported status via IOMMU_GET_HW_INFOShameer Kolothum-0/+4
If the IOMMU driver reports that ATS is not supported for a device, set the IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED flag in the returned hardware capabilities. This uses a negative flag for UAPI compatibility. Existing userspace assumes ATS is supported if no flag is present. This also ensures that new userspace works correctly on both old and new kernels, where a zero value implies ATS support. When this flag is set, ATS cannot be used for the device. When it is clear, ATS may be enabled when an appropriate HWPT is attached. Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-03-17iommu: Add device ATS supported capabilityShameer Kolothum-0/+11
PCIe ATS may be disabled by platform firmware, root complex limitations, or kernel policy even when a device advertises the ATS capability in its PCI configuration space. Add a new IOMMU_CAP_PCI_ATS_SUPPORTED capability to allow IOMMU drivers to report the effective ATS decision for a device. When this capability is true for a device, ATS may be enabled for that device, but it does not imply that ATS is currently enabled. A subsequent patch will extend iommufd to expose the effective ATS status to userspace. Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-03-17iommu/amd: Block identity domain when SNP enabledJoe Damato-1/+14
Previously, commit 8388f7df936b ("iommu/amd: Do not support IOMMU_DOMAIN_IDENTITY after SNP is enabled") prevented users from changing the IOMMU domain to identity if SNP was enabled. This resulted in an error when writing to sysfs: # echo "identity" > /sys/kernel/iommu_groups/50/type -bash: echo: write error: Cannot allocate memory However, commit 4402f2627d30 ("iommu/amd: Implement global identity domain") changed the flow of the code, skipping the SNP guard and allowing users to change the IOMMU domain to identity after a machine has booted. Once the user does that, they will probably try to bind and the device/driver will start to do DMA which will trigger errors: iommu ivhd3: AMD-Vi: Event logged [ILLEGAL_DEV_TABLE_ENTRY device=0000:43:00.0 pasid=0x00000 address=0x3737b01000 flags=0x0020] iommu ivhd3: AMD-Vi: Control Reg : 0xc22000142148d AMD-Vi: DTE[0]: 6000000000000003 AMD-Vi: DTE[1]: 0000000000000001 AMD-Vi: DTE[2]: 2000003088b3e013 AMD-Vi: DTE[3]: 0000000000000000 bnxt_en 0000:43:00.0 (unnamed net_device) (uninitialized): Error (timeout: 500015) msg {0x0 0x0} len:0 iommu ivhd3: AMD-Vi: Event logged [ILLEGAL_DEV_TABLE_ENTRY device=0000:43:00.0 pasid=0x00000 address=0x3737b01000 flags=0x0020] iommu ivhd3: AMD-Vi: Control Reg : 0xc22000142148d AMD-Vi: DTE[0]: 6000000000000003 AMD-Vi: DTE[1]: 0000000000000001 AMD-Vi: DTE[2]: 2000003088b3e013 AMD-Vi: DTE[3]: 0000000000000000 bnxt_en 0000:43:00.0: probe with driver bnxt_en failed with error -16 To prevent this from happening, create an attach wrapper for identity_domain_ops which returns EINVAL if amd_iommu_snp_en is true. With this commit applied: # echo "identity" > /sys/kernel/iommu_groups/62/type -bash: echo: write error: Invalid argument Fixes: 4402f2627d30 ("iommu/amd: Implement global identity domain") Signed-off-by: Joe Damato <joe@dama.to> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-03-17iommu/sva: Fix crash in iommu_sva_unbind_device()Lizhi Hou-6/+6
domain->mm->iommu_mm can be freed by iommu_domain_free(): iommu_domain_free() mmdrop() __mmdrop() mm_pasid_drop() After iommu_domain_free() returns, accessing domain->mm->iommu_mm may dereference a freed mm structure, leading to a crash. Fix this by moving the code that accesses domain->mm->iommu_mm to before the call to iommu_domain_free(). Fixes: e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for kernel address space") Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-03-17iommupt: Avoid rewalking during mapJason Gunthorpe-59/+147
Currently the core code provides a simplified interface to drivers where it fragments a requested multi-page map into single page size steps after doing all the calculations to figure out what page size is appropriate. Each step rewalks the page tables from the start. Since iommupt has a single implementation of the mapping algorithm it can internally compute each step as it goes while retaining its current position in the walk. Add a new function pt_pgsz_count() which computes the same page size fragement of a large mapping operations. Compute the next fragment when all the leaf entries of the current fragement have been written, then continue walking from the current point. The function pointer is run through pt_iommu_ops instead of iommu_domain_ops to discourage using it outside iommupt. All drivers with their own page tables should continue to use the simplified map_pages() style interfaces. Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-03-17iommupt: Directly call iommupt's unmap_range()Jason Gunthorpe-31/+25
The common algorithm in iommupt does not require the iommu_pgsize() calculations, it can directly unmap any arbitrary range. Add a new function pointer to directly call an iommupt unmap_range op and make __iommu_unmap() call it directly. Gives about a 5% gain on single page unmappings. The function pointer is run through pt_iommu_ops instead of iommu_domain_ops to discourage using it outside iommupt. All drivers with their own page tables should continue to use the simplified map/unmap_pages() style interfaces. Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-03-17iommu/riscv: Stop polling when CQCSR reports an errorFangyu Yu-0/+3
The cmdq wait loop busy-polls the consumer index until it advances or the software timeout expires. If the IOMMU has already signaled a command queue failure in CQCSR, continuing to poll for progress is pointless. Make riscv_iommu_queue_wait() also terminate the poll when any of these CQCSR error bits are observed. This helps the caller return earlier in failure cases and avoids spinning until the full timeout interval when the hardware has already reported an error. On single-core systems in particular, the current busy-wait can delay servicing the command-timeout interrupt until the software timeout expires (90s by default). Fixes: 856c0cfe5c5f ("iommu/riscv: Command and fault queue support") Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-03-17net: usb: aqc111: Do not perform PM inside suspend callbackNikola Z. Ivanov-6/+6
syzbot reports "task hung in rpm_resume" This is caused by aqc111_suspend calling the PM variant of its write_cmd routine. The simplified call trace looks like this: rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen. At this point we block another task which holds rtnl_lock and locks up the whole networking stack. Fix this by replacing the write_cmd calls with their _nopm variants Reported-by: syzbot+48dc1e8dfc92faf1124c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=48dc1e8dfc92faf1124c Fixes: e58ba4544c77 ("net: usb: aqc111: Add support for wake on LAN by MAGIC packet") Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com> Link: https://patch.msgid.link/20260313141643.1181386-1-zlatistiv@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-17iommu: Fix mapping check for 0x0 to avoid re-mapping itAntheas Kapenekakis-1/+5
Commit 789a5913b29c ("iommu/amd: Use the generic iommu page table") introduces the shared iommu page table for AMD IOMMU. Some bioses contain an identity mapping for address 0x0, which is not parsed properly (e.g., certain Strix Halo devices). This causes the DMA components of the device to fail to initialize (e.g., the NVMe SSD controller), leading to a failed post. Specifically, on the GPD Win 5, the NVME and SSD GPU fail to mount, making collecting errors difficult. While debugging, it was found that a -EADDRINUSE error was emitted and its source was traced to iommu_iova_to_phys(). After adding some debug prints, it was found that phys_addr becomes 0, which causes the code to try to re-map the 0 address and fail, causing a cascade leading to a failed post. This is because the GPD Win 5 contains a 0x0-0x1 identity mapping for DMA devices, causing it to be repeated for each device. The cause of this failure is the following check in iommu_create_device_direct_mappings(), where address aliasing is handled via the following check: ``` phys_addr = iommu_iova_to_phys(domain, addr); if (!phys_addr) { map_size += pg_size; continue; } ```` Obviously, the iommu_iova_to_phys() signature is faulty and aliases unmapped and 0 together, causing the allocation code to try to re-allocate the 0 address per device. However, it has too many instantiations to fix. Therefore, use a ternary so that when addr is 0, the check is done for address 1 instead. Suggested-by: Robin Murphy <robin.murphy@arm.com> Fixes: 789a5913b29c ("iommu/amd: Use the generic iommu page table") Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
generated by cgit v1.2.3 (git 2.46.0) at 2026-07-07 14:28:08 +0000