summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-10-31drm/panel: ilitek-ili9882t: Add support for Ilitek IL79900A-based panelsLangyan Ye
The Ilitek IL79900A display controller is similar to the ILI9882T and can be supported within the existing `panel-ilitek-ili9882t.c` driver. This patch extends the ILI9882T driver to handle IL79900A-based panels, such as the Tianma TL121BVMS07-00. The IL79900A uses a similar command sequence and initialization flow, with minor differences in power supply configuration and timing. Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251031100447.253164-3-yelangyan@huaqin.corp-partner.google.com
2025-10-31drm/sched: Fix comment in drm_sched_run_job_work()Philipp Stanner
drm_sched_run_job_work() contains a comment which explains that an entity being NULL means that there is no more work to do. It can, however, also mean that there is work, but the scheduler doesn't have enough credits to process the jobs right now. Provide this detail in the comment. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251028134602.94125-3-phasta@kernel.org
2025-10-31drm/i915/gt: Use standard API for seqcount read in TLB invalidationAndi Shyti
seqprop_sequence() is not intended for use outside seqlock.h. Although it is accessible as a macro, it is meant to be used only internally within the header. Replace it with its proper wrapper, raw_read_seqcount(). Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Co-developed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@linux.intel.com> Cc: Christoph Lameter (Ampere) <cl@gentwo.org> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Link: https://lore.kernel.org/r/20251023132802.654061-1-andi.shyti@linux.intel.com
2025-10-31crypto: qat - use simple_strtoull to improve qat_uclo_parse_numThorsten Blum
Replace the manual string copying and parsing logic with a call to simple_strtoull() to simplify and improve qat_uclo_parse_num(). Ensure that the parsed number does not exceed UINT_MAX, and add an approximate upper-bound check (no more than 19 digits) to guard against overflow. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Acked-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-10-31crypto: hisilicon/qm - add missing default in switch in qm_vft_data_cfgnieweiqiang
Add default case to avoid warnings and meet code style requirements. Signed-off-by: nieweiqiang <nieweiqiang@huawei.com> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-10-31crypto: hisilicon/sgl - remove unnecessary checks for curr_hw_sgl errornieweiqiang
Before calling acc_get_sgl(), the mem_block has already been created. acc_get_sgl() will not return NULL or any other error. so the return value check can be removed. Signed-off-by: nieweiqiang <nieweiqiang@huawei.com> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-10-31crypto: hisilicon/qm - add concurrency protection for variable err_thresholdnieweiqiang
The isolate_strategy_store function is not protected by a lock. If sysfs operations and functions that depend on the err_threshold variable,such as qm_hw_err_isolate(), execute concurrently, the outcome will be unpredictable. Therefore, concurrency protection should be added for the err_threshold variable. Signed-off-by: nieweiqiang <nieweiqiang@huawei.com> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-10-31crypto: hisilicon/qm - add the save operation of eqe and aeqenieweiqiang
The eqe and aeqe are device updated values that include the valid bit and queue number. In the current process, there is no memory barrier added, so it cannot be guaranteed that the valid bit is read before other processes are executed. Since eqe and aeqe are only 4 bytes and the device writes them to memory in a single operation, saving the values of eqe and aeqe ensures that the valid bit and queue number read by the CPU were written by the device simultaneously. Signed-off-by: nieweiqiang <nieweiqiang@huawei.com> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-10-31crypto: qce - Provide dev_err_probe() status on DMA failureBjorn Andersson
On multiple occasions the qce device have shown up in devices_deferred, without the explanation that this came from the failure to acquire the DMA channels from the associated BAM. Use dev_err_probe() to associate this context with the failure to faster pinpoint the culprit when this happens in the future. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: David Heidelberg <david@ixit.cz> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-10-31drm/i915: Wait for page_sizes_gtt in gtt selftest on CHV/BXT+VTDJanusz Krzysztofik
VMA pinning to GGTT is now commited asynchronously in CHV / BXT+VDT environments to avoid lock inversion among reservation_ww and cpu_hotplug locks, the latter acquired from stop_machine(). Then, vma->resource->page_sizes_gtt the test uses as shift count may still be not populated (equal 0) after i915_vma_pin() returns. Wait for VMA bind completion in those cases to avoid shift-out-of-bounds kernel warnings and the test case failing with -EBADSLT. v2: Explain why VMA pinning is commited asynchronously on CHV/BXT+VTD (Krzysztof), - use more precise wording in commit description. Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Acked-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20251023082925.351307-8-janusz.krzysztofik@linux.intel.com
2025-10-31drm/i915: Wait longer for threads in migrate selftest on CHV/BXT+VTDJanusz Krzysztofik
When running on a Cherryview, or on a Broxton with VTD enabled, pinning of a VMA to GGTT is now committed asynchronously to avoid lock inversion among reservation_ww and cpu_hotplug locks, the latter acquired from stop_machine(). That may defer further processing of resources that depend on that VMA. As a consequence, a 10ms delay in a multithreaded migrate test case may occur too short and still incomplete threads may be interrupted, and the test case may fail with -ERESTARTSYS or -EINTR error code returned by any of those threads. Extend the delay to empirically determined 100ms on affected platforms. v3: Add an in-line comment that explains why 100ms (Andi). v2: Fix spelling (Sebastian, Krzysztof), - explain why VMA pinning is commited asynchronously on CHV/BXT+VTD (Krzysztof). Cc: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Acked-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20251023082925.351307-7-janusz.krzysztofik@linux.intel.com
2025-10-31drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTDJanusz Krzysztofik
On completion of i915_vma_pin_ww(), a synchronous variant of dma_fence_work_commit() is called. When pinning a VMA to GGTT address space on a Cherry View family processor, or on a Broxton generation SoC with VTD enabled, i.e., when stop_machine() is then called from intel_ggtt_bind_vma(), that can potentially lead to lock inversion among reservation_ww and cpu_hotplug locks. [86.861179] ====================================================== [86.861193] WARNING: possible circular locking dependency detected [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U [86.861226] ------------------------------------------------------ [86.861238] i915_module_loa/1432 is trying to acquire lock: [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50 [86.861290] but task is already holding lock: [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] which lock already depends on the new lock. [86.862251] the existing dependency chain (in reverse order) is: [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0}: [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f0 [86.862454] kernel_init_freeable+0x3cd/0x680 [86.862470] kernel_init+0x1b/0x200 [86.862482] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm+0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [86.862635] iterate_dir+0xcf/0x2b0 [86.862648] __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){++++}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908] kernel_init+0x1b/0x200 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969] __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320 [86.863012] __cpuhp_setup_state+0xb0/0x220 [86.863026] page_alloc_init_cpuhp+0x2d/0x60 [86.863041] mm_core_init+0x22/0x2d0 [86.863054] start_kernel+0x576/0xbd0 [86.863068] x86_64_start_reservations+0x18/0x30 [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [86.863135] __lock_acquire+0x1635/0x2810 [86.863152] lock_acquire+0xc4/0x2f0 [86.863166] cpus_read_lock+0x41/0x100 [86.863180] stop_machine+0x1c/0x50 [86.863194] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.863987] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.864735] __vma_bind+0x55/0x70 [i915] [86.865510] fence_work+0x26/0xa0 [i915] [86.866248] fence_notify+0xa1/0x140 [i915] [86.866983] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.867719] i915_sw_fence_commit+0x39/0x60 [i915] [86.868453] i915_vma_pin_ww+0x462/0x1360 [i915] [86.869228] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.870001] initial_plane_vma+0x307/0x840 [i915] [86.870774] intel_initial_plane_config+0x33f/0x670 [i915] [86.871546] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.872330] i915_driver_probe+0x7fa/0xe80 [i915] [86.873057] i915_pci_probe+0xe6/0x220 [i915] [86.873782] local_pci_probe+0x47/0xb0 [86.873802] pci_device_probe+0xf3/0x260 [86.873817] really_probe+0xf1/0x3c0 [86.873833] __driver_probe_device+0x8c/0x180 [86.873848] driver_probe_device+0x24/0xd0 [86.873862] __driver_attach+0x10f/0x220 [86.873876] bus_for_each_dev+0x7f/0xe0 [86.873892] driver_attach+0x1e/0x30 [86.873904] bus_add_driver+0x151/0x290 [86.873917] driver_register+0x5e/0x130 [86.873931] __pci_register_driver+0x7d/0x90 [86.873945] i915_pci_register_driver+0x23/0x30 [i915] [86.874678] i915_init+0x37/0x120 [i915] [86.875347] do_one_initcall+0x60/0x3f0 [86.875369] do_init_module+0x97/0x2a0 [86.875385] load_module+0x2c54/0x2d80 [86.875398] init_module_from_file+0x96/0xe0 [86.875413] idempotent_init_module+0x117/0x330 [86.875426] __x64_sys_finit_module+0x77/0x100 [86.875440] x64_sys_call+0x24de/0x2660 [86.875454] do_syscall_64+0x91/0xe90 [86.875470] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.875486] other info that might help us debug this: [86.875502] Chain exists of: cpu_hotplug_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [86.875539] Possible unsafe locking scenario: [86.875552] CPU0 CPU1 [86.875563] ---- ---- [86.875573] lock(reservation_ww_class_mutex); [86.875588] lock(reservation_ww_class_acquire); [86.875606] lock(reservation_ww_class_mutex); [86.875624] rlock(cpu_hotplug_lock); [86.875637] *** DEADLOCK *** [86.875650] 3 locks held by i915_module_loa/1432: [86.875663] #0: ffff888101f5c1b0 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x104/0x220 [86.875699] #1: ffffc90002e0b4a0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.876512] #2: ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.877305] stack backtrace: [86.877326] CPU: 0 UID: 0 PID: 1432 Comm: i915_module_loa Tainted: G U 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 PREEMPT(voluntary) [86.877334] Tainted: [U]=USER [86.877336] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0079.2020.0420.1316 04/20/2020 [86.877339] Call Trace: [86.877344] <TASK> [86.877353] dump_stack_lvl+0x91/0xf0 [86.877364] dump_stack+0x10/0x20 [86.877369] print_circular_bug+0x285/0x360 [86.877379] check_noncircular+0x135/0x150 [86.877390] __lock_acquire+0x1635/0x2810 [86.877403] lock_acquire+0xc4/0x2f0 [86.877408] ? stop_machine+0x1c/0x50 [86.877422] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878173] cpus_read_lock+0x41/0x100 [86.878182] ? stop_machine+0x1c/0x50 [86.878191] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878916] stop_machine+0x1c/0x50 [86.878927] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.879652] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.880375] __vma_bind+0x55/0x70 [i915] [86.881133] fence_work+0x26/0xa0 [i915] [86.881851] fence_notify+0xa1/0x140 [i915] [86.882566] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.883286] i915_sw_fence_commit+0x39/0x60 [i915] [86.884003] i915_vma_pin_ww+0x462/0x1360 [i915] [86.884756] ? i915_vma_pin.constprop.0+0x6c/0x1d0 [i915] [86.885513] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.886281] initial_plane_vma+0x307/0x840 [i915] [86.887049] intel_initial_plane_config+0x33f/0x670 [i915] [86.887819] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.888587] i915_driver_probe+0x7fa/0xe80 [i915] [86.889293] ? mutex_unlock+0x12/0x20 [86.889301] ? drm_privacy_screen_get+0x171/0x190 [86.889308] ? acpi_dev_found+0x66/0x80 [86.889321] i915_pci_probe+0xe6/0x220 [i915] [86.890038] local_pci_probe+0x47/0xb0 [86.890049] pci_device_probe+0xf3/0x260 [86.890058] really_probe+0xf1/0x3c0 [86.890067] __driver_probe_device+0x8c/0x180 [86.890072] driver_probe_device+0x24/0xd0 [86.890078] __driver_attach+0x10f/0x220 [86.890083] ? __pfx___driver_attach+0x10/0x10 [86.890088] bus_for_each_dev+0x7f/0xe0 [86.890097] driver_attach+0x1e/0x30 [86.890101] bus_add_driver+0x151/0x290 [86.890107] driver_register+0x5e/0x130 [86.890113] __pci_register_driver+0x7d/0x90 [86.890119] i915_pci_register_driver+0x23/0x30 [i915] [86.890833] i915_init+0x37/0x120 [i915] [86.891482] ? __pfx_i915_init+0x10/0x10 [i915] [86.892135] do_one_initcall+0x60/0x3f0 [86.892145] ? __kmalloc_cache_noprof+0x33f/0x470 [86.892157] do_init_module+0x97/0x2a0 [86.892164] load_module+0x2c54/0x2d80 [86.892168] ? __kernel_read+0x15c/0x300 [86.892185] ? kernel_read_file+0x2b1/0x320 [86.892195] init_module_from_file+0x96/0xe0 [86.892199] ? init_module_from_file+0x96/0xe0 [86.892211] idempotent_init_module+0x117/0x330 [86.892224] __x64_sys_finit_module+0x77/0x100 [86.892230] x64_sys_call+0x24de/0x2660 [86.892236] do_syscall_64+0x91/0xe90 [86.892243] ? irqentry_exit+0x77/0xb0 [86.892249] ? sysvec_apic_timer_interrupt+0x57/0xc0 [86.892256] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.892261] RIP: 0033:0x7303e1b2725d [86.892271] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8b bb 0d 00 f7 d8 64 89 01 48 [86.892276] RSP: 002b:00007ffddd1fdb38 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [86.892281] RAX: ffffffffffffffda RBX: 00005d771d88fd90 RCX: 00007303e1b2725d [86.892285] RDX: 0000000000000000 RSI: 00005d771d893aa0 RDI: 000000000000000c [86.892287] RBP: 00007ffddd1fdbf0 R08: 0000000000000040 R09: 00007ffddd1fdb80 [86.892289] R10: 00007303e1c03b20 R11: 0000000000000246 R12: 00005d771d893aa0 [86.892292] R13: 0000000000000000 R14: 00005d771d88f0d0 R15: 00005d771d895710 [86.892304] </TASK> Call asynchronous variant of dma_fence_work_commit() in that case. v3: Provide more verbose in-line comment (Andi), - mention target environments in commit message. Fixes: 7d1c2618eac59 ("drm/i915: Take reservation lock around i915_vma_pin.") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14985 Cc: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Acked-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20251023082925.351307-6-janusz.krzysztofik@linux.intel.com
2025-10-31crypto: ti - Add support for AES-XTS in DTHEv2 driverT Pratham
Add support for XTS mode of operation for AES algorithm in the AES Engine of the DTHEv2 hardware cryptographic engine. Signed-off-by: T Pratham <t-pratham@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-10-31drm/ttm: Add an allocation flag to propagate -ENOSPC on OOMTvrtko Ursulin
Some graphics APIs differentiate between out-of-graphics-memory and out-of-host-memory (system memory). Add a device init flag to have -ENOSPC propagated from the resource managers instead of being converted to -ENOMEM, to aid driver stacks in determining what error code to return or whether corrective action can be taken at the driver level. Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-7-tvrtko.ursulin@igalia.com
2025-10-31drm/amdgpu: Configure max beneficial TTM pool allocation orderTvrtko Ursulin
Let the TTM pool allocator know that we can afford for it to expend less effort for satisfying contiguous allocations larger than 2MiB. The latter is the maximum relevant PTE entry size and the driver and hardware are happy to get larger blocks only opportunistically. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-6-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: Allow drivers to specify maximum beneficial TTM pool sizeTvrtko Ursulin
GPUs typically benefit from contiguous memory via reduced TLB pressure and improved caching performance, where the maximum size of contiguous block which adds a performance benefit is related to hardware design. TTM pool allocator by default tries (hard) to allocate up to the system MAX_PAGE_ORDER blocks. This varies by the CPU platform and can also be configured via Kconfig. If that limit was set to be higher than the GPU can make an extra use of, lets allow the individual drivers to let TTM know over which allocation order can the pool allocator afford to make a little bit less effort with. We implement this by disabling direct reclaim for those allocations, which reduces the allocation latency and lowers the demands on the page allocator, in cases where expending this effort is not critical for the GPU in question. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-5-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: Replace multiple booleans with flags in device initTvrtko Ursulin
Multiple consecutive boolean function arguments are usually not very readable. Replace the ones in ttm_device_init() with flags with the additional benefit of soon being able to pass in more data with just a one off code base churning cost. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sui Jingfeng <suijingfeng@loongson.cn> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zack Rusin <zack.rusin@broadcom.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> # For xe Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-4-tvrtko.ursulin@igalia.com [tursulin: fixup checkpatch while applying]
2025-10-31HID: nintendo: Reduce JC_SUBCMD_RATE_MAX_ATTEMPTSWilly Huang
The JC_SUBCMD_RATE_MAX_ATTEMPTS constant is currently set to 500. In a worst-case scenario where all attempts consistently fail, this could cause the loop to block for up to 60000 ms (500 * 60ms * 2, including the additional retry after a timeout). This change lowers the maximum potential blocking time to 3000 ms (25 * 60ms * 2), improving system responsiveness and efficiency. Signed-off-by: Willy Huang <willyhuang@google.com> Reviewed-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-31HID: hid-input: Extend Elan ignore battery quirk to USBMario Limonciello (AMD)
USB Elan devices have the same problem as the I2C ones with a fake battery device showing up. Reviewed-by: Hans de Goede <hansg@kernel.org> Reported-by: André Barata <andretiagob@protonmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220722 Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-31drm/ttm: Replace multiple booleans with flags in pool initTvrtko Ursulin
Multiple consecutive boolean function arguments are usually not very readable. Replace the ones in ttm_pool_init() with flags with the additional benefit of soon being able to pass in more data with just this one code base churning cost. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-3-tvrtko.ursulin@igalia.com
2025-10-31HID: hid-ntrig: Prevent memory leak in ntrig_report_version()Masami Ichikawa
Use a scope-based cleanup helper for the buffer allocated with kmalloc() in ntrig_report_version() to simplify the cleanup logic and prevent memory leaks (specifically the !hid_is_usb()-case one). [jkosina@suse.com: elaborate on the actual existing leak] Fixes: 185c926283da ("HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()") Signed-off-by: Masami Ichikawa <masami256@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-31drm/ttm: Add getter for some pool propertiesTvrtko Ursulin
No functional change but to allow easier refactoring in the future. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-2-tvrtko.ursulin@igalia.com
2025-10-31drm: include drm_print.h where neededJani Nikula
There are a gazillion files that depend on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In preparation for removing those includes, explicitly include drm_print.h where needed. Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com
2025-10-30drm/xe/gt_throttle: Drop individual show functionsLucas De Marchi
They are all doing the same thing with the mask being the param. Just declare our own attribute to store the mask and provide a single function. Another common pattern is to define the show function in the macro, however on follow up work the mask may be used for returning more information, so it'd need to be stored in any case. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-7-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe: Improve freq and throttle documentationLucas De Marchi
Add xe_gt_throttle under the "GT Frequency Management" and improve the narrative making sure the documentation for both *_freq and throttle/* attributes follow the same style. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-6-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Tidy up attribute definitionLucas De Marchi
Move the attribute definitions to be grouped together rather than near the show() function: checkpatch keeps complaining about the missing newline when defining new attributes and it reads better to group everything, which should match e.g. the xe_pmu.c style. While grouping them, also define a THROTTLE_ATTR_RO(), similar to DEVICE_ATTR_RO(), and use it to define all attributes. This makes it shorter and with a familiar syntax. Finally, during the cri_throttle_attrs[] array definition, also highlight what's coming from common attributes and what is CRI-specific. These 3 things could be done as separate commits, but they are all about the same thing: reduce the attribute definition verbosity and are very simple and mechanical. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-5-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Add throttle_to_gt()Lucas De Marchi
Reduce boilerplate code by adding a helper to go directly from the throttle kobject to the gt. Note that there's already a kobj_to_gt(), but that actually converts our kobj_gt object to gt. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-4-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Always read and maskLucas De Marchi
Use a single function to read and mask the value the callers will be interested in. This reduces the risk of a caller using a plain call to xe_gt_throttle_get_limit_reasons() without applying any mask, which can return unexpected bits for future platforms. Select which reg and mask it's going to be used according to the platform and gt type and always use that one function. There was an odd xe_gt_dbg() when reading the status, which is not done for any other throttle/* sysfs file, so just make the status be as special as everybody else. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-3-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Tidy up perf reasons readingLucas De Marchi
There's no need to be so verbose with two functions per bit: read_reason_xxxxx() and reason_xxxxx_show(). Drop the former and just use a new is_throttled_by() that receives the mask as parameter. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-2-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/cri: Add new performance limit reasons bitsSk Anirban
Crescent Island has some additional and different bits for performance limit reasons. Add the new definitions and use them for CRI. Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-1-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30cxgb4: flower: add support for fragmentationHarshita V Rajput
This patch adds support for matching fragmented packets in tc flower filters. Previously, commit 93a8540aac72 ("cxgb4: flower: validate control flags") added a check using flow_rule_match_has_control_flags() to reject any rules with control flags, as the driver did not support fragmentation at that time. Now, with this patch, support for FLOW_DIS_IS_FRAGMENT is added: - The driver checks for control flags using flow_rule_is_supp_control_flags(), as recommended in commit d11e63119432 ("flow_offload: add control flag checking helpers"). - If the fragmentation flag is present, the driver sets `fs->val.frag` and `fs->mask.frag` accordingly in the filter specification. Since fragmentation is now supported, the earlier check that rejected all control flags (flow_rule_match_has_control_flags()) has been removed. Signed-off-by: Harshita V Rajput <harshitha.vr@chelsio.com> Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251028075255.1391596-1-harshitha.vr@chelsio.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-30Merge tag 'acpi-6.18-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These fix three ACPI driver issues and add version checks to two ACPI table parsers: - Call input_free_device() on failing input device registration as necessary (and mentioned in the input subsystem documentation) in the ACPI button driver (Kaushlendra Kumar) - Fix use-after-free in acpi_video_switch_brightness() by canceling a delayed work during tear-down (Yuhao Jiang) - Use platform device for devres-related actions in the ACPI fan driver to allow device-managed resources to be cleaned up properly (Armin Wolf) - Add version checks to the MRRM and SPCR table parsers (Tony Luck and Punit Agrawal)" * tag 'acpi-6.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: SPCR: Check for table version when using precise baudrate ACPI: MRRM: Check revision of MRRM table ACPI: fan: Use platform device for devres-related actions ACPI: fan: Use ACPI handle when retrieving _FST ACPI: video: Fix use-after-free in acpi_video_switch_brightness() ACPI: button: Call input_free_device() on failing input device registration
2025-10-30Merge tag 'pm-6.18-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix three regressions, two recent ones and one introduced during the 6.17 development cycle: - Add an exit latency check to the menu cpuidle governor in the case when it considers using a real idle state instead of a polling one to address a performance regression (Rafael Wysocki) - Revert an attempted cleanup of a system suspend code path that introduced a regression elsewhere (Samuel Wu) - Allow pm_restrict_gfp_mask() to be called multiple times in a row and adjust pm_restore_gfp_mask() accordingly to avoid having to play nasty games with these calls during hibernation (Rafael Wysocki)" * tag 'pm-6.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM: sleep: Allow pm_restrict_gfp_mask() stacking cpuidle: governors: menu: Select polling state in some more cases Revert "PM: sleep: Make pm_wakeup_clear() call more clear"
2025-10-30Merge tag 'fbdev-for-6.18-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev Pull fbdev fixes from Helge Deller: - atyfb: Avoid hard lock up when PLL not initialized (Daniel Palmer) - pvr2fb: Fix build error when CONFIG_PVR2_DMA enabled (Florian Fuchs) - bitblit: Fix out-of-bounds read in bit_putcs* (Junjie Cao) - valkyriefb: Fix reference count leak (Miaoqian Lin) - fbcon: Fix slab-use-after-free in fb_mode_is_equal (Quanmin Yan) - fb.h: Fix typo in "vertical" (Piyush Choudhary) * tag 'fbdev-for-6.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev: fbdev: atyfb: Check if pll_ops->init_pll failed fbcon: Set fb_display[i]->mode to NULL when the mode is released fbdev: bitblit: bound-check glyph index in bit_putcs* fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS fbdev: valkyriefb: Fix reference count leak in valkyriefb_init video: fb: Fix typo in comment in fb.h
2025-10-31platform/chrome: cros_ec_lightbar: Check if ec supports suspend commandsBrady Norander
The Chromebook Pixel 2013 (Link)'s ec does not support the lightbar manual suspend commands. As a result, attempting to suspend the device fails and prints the following error: cros-ec-lightbar cros-ec-lightbar.3.auto: PM: dpm_run_callback(): platform_pm_suspend returns -22 cros-ec-lightbar cros-ec-lightbar.3.auto: PM: failed to suspend: error -22 PM: Some devices failed to suspend, or early wake event detected Check the return value of lb_manual_suspend_ctrl in cros_ec_lightbar_probe and disable manual suspend control if -EINVAL is returned. Signed-off-by: Brady Norander <bradynorander@gmail.com> Reviewed-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20251030195910.8625-2-bradynorander@gmail.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2025-10-30Merge tag 'net-6.18-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from wireless, Bluetooth and netfilter. Current release - regressions: - tcp: fix too slow tcp_rcvbuf_grow() action - bluetooth: fix corruption in h4_recv_buf() after cleanup Previous releases - regressions: - mptcp: restore window probe - bluetooth: - fix connection cleanup with BIG with 2 or more BIS - fix crash in set_mesh_sync and set_mesh_complete - batman-adv: release references to inactive interfaces - nic: - ice: fix usage of logical PF id - sfc: fix potential memory leak in efx_mae_process_mport() Previous releases - always broken: - devmem: refresh devmem TX dst in case of route invalidation - netfilter: add seqadj extension for natted connections - wifi: - iwlwifi: fix potential use after free in iwl_mld_remove_link() - brcmfmac: fix crash while sending action frames in standalone AP Mode - eth: - mlx5e: cancel tls RX async resync request in error flows - ixgbe: fix memory leak and use-after-free in ixgbe_recovery_probe() - hibmcge: fix rx buf avl irq is not re-enabled in irq_handle issue - cxgb4: fix potential use-after-free in ipsec callback - nfp: fix memory leak in nfp_net_alloc()" * tag 'net-6.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (75 commits) net: sctp: fix KMSAN uninit-value in sctp_inq_pop net: devmem: refresh devmem TX dst in case of route invalidation net: stmmac: est: Fix GCL bounds checks net: stmmac: Consider Tx VLAN offload tag length for maxSDU net: stmmac: vlan: Disable 802.1AD tag insertion offload net/mlx5e: kTLS, Cancel RX async resync request in error flows net: tls: Cancel RX async resync request on rcd_delta overflow net: tls: Change async resync helpers argument net: phy: dp83869: fix STRAP_OPMODE bitmask selftests: net: use BASH for bareudp testing net: mctp: Fix tx queue stall net/mlx5: Don't zero user_count when destroying FDB tables net: usb: asix_devices: Check return value of usbnet_get_endpoints mptcp: zero window probe mib mptcp: restore window probe mptcp: fix MSG_PEEK stream corruption mptcp: drop bogus optimization in __mptcp_check_push() netconsole: Fix race condition in between reader and writer of userdata Documentation: netconsole: Remove obsolete contact people nfp: xsk: fix memory leak in nfp_net_alloc() ...
2025-10-30kbuild: Add '-fms-extensions' to areas with dedicated CFLAGSNathan Chancellor
This is a follow up to commit c4781dc3d1cf ("Kbuild: enable -fms-extensions") but in a separate change due to being substantially different from the initial submission. There are many places within the kernel that use their own CFLAGS instead of the main KBUILD_CFLAGS, meaning code written with the main kernel's use of '-fms-extensions' in mind that may be tangentially included in these areas will result in "error: declaration does not declare anything" messages from the compiler. Add '-fms-extensions' to all these areas to ensure consistency, along with -Wno-microsoft-anon-tag to silence clang's warning about use of the extension that the kernel cares about using. parisc does not build with clang so it does not need this warning flag. LoongArch does not need it either because -W flags from KBUILD_FLAGS are pulled into cflags-vdso. Reported-by: Christian Brauner <brauner@kernel.org> Closes: https://lore.kernel.org/20251030-meerjungfrau-getrocknet-7b46eacc215d@brauner/ Reviewed-by: Christian Brauner <brauner@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2025-10-31Merge branch 'icc-sa8775p' into icc-nextGeorgi Djakov
This enables QoS configuration for QNOC type device which can be found on SA8775P platform. It enables QoS configuration for master ports with predefined priority and urgency forwarding. This helps in prioritizing the traffic originating from different interconnect masters at NOC. The system may function normally without this feature. However, enabling QoS helps optimize latency and bandwidth across subsystems like CPU, GPU, and multimedia engines, which becomes important in high-throughput scenarios. This is a feature aimed at performance enhancement to improve system performance under concurrent workloads. * icc-sa8775p dt-bindings: interconnect: add reg and clocks properties to enable QoS on sa8775p interconnect: qcom: sa8775p: enable QoS configuration Link: https://lore.kernel.org/r/20251001073344.6599-1-odelu.kukatla@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2025-10-31Merge branch 'icc-sdx75' into icc-nextGeorgi Djakov
Drop the QPIC interconnect and BCM nodes for the SDX75 SoC. The reason is that this QPIC BCM resource is already defined as a RPMh clock in clk-rpmh driver as like other SDX SoCs. So it is wrong to describe the same resource in two different providers. Also, without this series, the NAND driver fails to probe on SDX75 as the interconnect sync state disables the QPIC nodes as there were no clients voting for this ICC resource. However, the NAND driver had already voted for this BCM resource through the clk-rpmh driver. Since both votes come from Linux, RPMh was unable to distinguish between these two and ends up disabling the resource during sync state. * icc-sdx75 interconnect: qcom: sdx75: Drop QPIC interconnect and BCM nodes dt-bindings: interconnect: qcom: Drop QPIC_CORE IDs Link: https://lore.kernel.org/r/20250926-sdx75-icc-v2-0-20d6820e455c@oss.qualcomm.com> Signed-off-by: Georgi Djakov <djakov@kernel.org>
2025-10-31Merge branch 'icc-msm8996' into icc-nextGeorgi Djakov
The lack of the interconnects for the USB2 host might result in the register writes for the PHY not reaching the PHY and thus the PLL not locking up, resulting in -EBUSY errors for the USB host on the platform. Add missing interconnect link and add interconnect paths to the USB2 device. * icc-msm8996 interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller Link: https://lore.kernel.org/r/20251002-fix-msm8996-icc-v1-0-a36a05d1f869@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2025-10-31interconnect: debugfs: Fix incorrect error handling for NULL pathKuan-Wei Chiu
The icc_commit_set() function, used by the debugfs interface, checks the validity of the global cur_path pointer using IS_ERR_OR_NULL(). However, in the specific case where cur_path is NULL, while IS_ERR_OR_NULL(NULL) correctly evaluates to true, the subsequent call to PTR_ERR(NULL) returns 0. This causes the function to return a success code (0) instead of an error, misleading the user into believing their bandwidth request was successfully committed when, in fact, no operation was performed. Fix this by adding an explicit check to return -EINVAL if cur_path is NULL. This prevents silent failures and ensures that an invalid operational sequence is immediately and clearly reported as an error. Fixes: 770c69f037c1 ("interconnect: Add debugfs test client") Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Link: https://lore.kernel.org/r/20251010151447.2289779-1-visitorckw@gmail.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2025-10-31interconnect: qcom: sdx75: Drop QPIC interconnect and BCM nodesRaviteja Laggyshetty
As like other SDX SoCs, SDX75 SoC's QPIC BCM resource was modeled as a RPMh clock in clk-rpmh driver. However, for SDX75, this resource was also described as an interconnect and BCM node mistakenly. It is incorrect to describe the same resource in two different providers, as it will lead to votes from clients overriding each other. Hence, drop the QPIC interconnect and BCM nodes and let the clients use clk-rpmh driver to vote for this resource. Without this change, the NAND driver fails to probe on SDX75, as the interconnect sync state disables the QPIC nodes as there were no clients voting for this ICC resource. However, the NAND driver had already voted for this BCM resource through the clk-rpmh driver. Since both votes come from Linux, RPMh was unable to distinguish between these two and ends up disabling the QPIC resource during sync state. Cc: stable@vger.kernel.org Fixes: 3642b4e5cbfe ("interconnect: qcom: Add SDX75 interconnect provider driver") Signed-off-by: Raviteja Laggyshetty <quic_rlaggysh@quicinc.com> [mani: dropped the reference to bcm_qp0, reworded description] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Lakshmi Sowjanya D <quic_laksd@quicinc.com> # on SDX75 Link: https://lore.kernel.org/r/20250926-sdx75-icc-v2-1-20d6820e455c@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2025-10-30accel/amdxdna: Fix incorrect command state for timed out jobLizhi Hou
When a command times out, mark it as ERT_CMD_STATE_TIMEOUT. Any other commands that are canceled due to this timeout should be marked as ERT_CMD_STATE_ABORT. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20251029193423.2430463-1-lizhi.hou@amd.com
2025-10-30Merge tag 'wireless-next-2025-10-30' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Not that many changes this time: - mac80211: - improved VHT radiotap reporting - S1G improvements - multi-radio monitor improvements - HT action frame handling on 6 GHz - mesh rate tracking improvements - CSA handling improvements - cfg80211: multi-radio debugfs - rt2x00: improvements for embedded platforms * tag 'wireless-next-2025-10-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: wifi: mac80211: Allow HT Action frame processing on 6 GHz when HE is supported wifi: rt2x00: add nvmem eeprom support wifi: mac80211: add RX flag to report radiotap VHT information net: wireless: Remove redundant pm_runtime_mark_last_busy() calls wifi: cfg80211: Add parameters to radio-specific debugfs directories wifi: cfg80211: Add debugfs support for multi-radio wiphy wifi: mac80211: fix missing RX bitrate update for mesh forwarding path wifi: cfg80211: default S1G chandef width to 1MHz wifi: mac80211: get probe response chan via ieee80211_get_channel_khz wifi: mac80211: reset CRC valid after CSA wifi: mac80211_hwsim: advertise puncturing feature support wifi: cfg80211/mac80211: validate radio frequency range for monitor mode wifi: rt2x00: check retval for of_get_mac_address ==================== Link: https://patch.msgid.link/20251030105355.13216-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31interconnect: qcom: sa8775p: enable QoS configurationOdelu Kukatla
Enable QoS configuration for master ports with predefinedi priority and urgency forwarding. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251001073344.6599-3-odelu.kukatla@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2025-10-30Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2025-10-29 (ice, i40e, idpf, ixgbe, igbvf) For ice: Michal converts driver to utilize Page Pool and libeth APIs. Conversion is based on similar changes done for iavf in order to simplify buffer management, improve maintainability, and increase code reuse across Intel Ethernet drivers. Additional details: https://lore.kernel.org/20250925092253.1306476-1-michal.kubiak@intel.com Alexander adds support for header split, configurable via ethtool. Grzegorz allows for use of 100Mbps on E825C SGMII devices. For i40e: Jay Vosburgh avoids sending link state changes to VF if it is already in the requested state. For idpf: Sreedevi removes duplicated defines. For ixgbe: Alok Tiwari fixes some typos. For igbvf: Alok Tiwari fixes output of VLAN warning message. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: igbvf: fix misplaced newline in VLAN add warning message ixgbe: fix typos in ixgbe driver comments idpf: remove duplicate defines in IDPF_CAP_RSS i40e: avoid redundant VF link state updates ice: Allow 100M speed for E825C SGMII device ice: implement configurable header split for regular Rx ice: switch to Page Pool ice: drop page splitting and recycling ice: remove legacy Rx and construct SKB ==================== Link: https://patch.msgid.link/20251029231218.1277233-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31interconnect: qcom: msm8996: add missing link to SLAVE_USB_HSDmitry Baryshkov
>From the initial submission the interconnect driver missed the link from SNOC_PNOC to the USB 2 configuration space. Add missing link in order to let the platform configure and utilize this path. Fixes: 7add937f5222 ("interconnect: qcom: Add MSM8996 interconnect provider driver") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251002-fix-msm8996-icc-v1-1-a36a05d1f869@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2025-10-30wifi: ath10k: use = {} to initialize bmi_target_info instead of memsetZhongqiu Han
Initialize the bmi_target_info structure using = {} at declaration time instead of calling memset() in each bus-specific code path. This simplifies the code and avoids an explicit memset. Signed-off-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251030130023.1836808-3-zhongqiu.han@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-10-30wifi: ath10k: use = {} to initialize pm_qos_request instead of memsetZhongqiu Han
Initialize the pm_qos_request structure using = {} instead of memset() in ath10k_download_fw(). This ensures the structure is properly zeroed before passing it to cpu_latency_qos_add_request(), and improves efficiency by avoiding an explicit runtime memset. Signed-off-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251030130023.1836808-2-zhongqiu.han@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-10-30wifi: ath12k: unassign arvif on scan vdev create failureRameshkumar Sundaram
During scan and remain-on-channel requests, a scan link vif (arvif) is assigned and a temporary vdev is created. If vdev creation fails, the assigned arvif is left attached until the virtual interface is removed, leaving a stale link in ahvif. Fix this by freeing the stale arvif and resetting the corresponding link in ahvif by calling ath12k_mac_unassign_link_vif() when vdev creation fails. While at it, propagate the actual error code from ath12k_mac_vdev_create() instead of returning -EINVAL in ath12k_mac_initiate_hw_scan(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: 477cabfdb776 ("wifi: ath12k: modify link arvif creation and removal for MLO") Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251026182254.1399650-3-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-13 09:58:34 +0000