aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-09-15drm/msm/hdmi_phy: fix runtime PM cleanup on probe failureGuangshuo Li1-2/+6
msm_hdmi_phy_probe() enables runtime PM before enabling the PHY resources and initializing the PLL, but failures from either operation return without calling the matching pm_runtime_disable(). The remove path disables runtime PM, but it is not called when probe fails. As a result, runtime PM remains enabled after an unsuccessful probe. Route failures after pm_runtime_enable() through a common error path and disable runtime PM before returning. This issue was found by manual code inspection. Fixes: 15b4a4523859 ("drm/msm/hdmi: Create a separate HDMI PHY driver") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/753043/ Link: https://lore.kernel.org/r/20260913085814.1509352-1-lgs201920130244@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-09-15drm/msm/dsi: round the byte clock rate after reparenting to the PHY PLLDmitry Baryshkov1-17/+19
DSI 6G v2.9 hosts (SM8650, SM8750, Kaanapali, etc.) reparent the byte and pixel RCGs to the DSI PHY PLL at runtime from dsi_link_clk_set_rate_6g_v2_9(), after the PHY has been enabled. However dsi_calc_clk_rate_6g() runs earlier, in order to compute the bit clock request for the PHY. At that point the byte RCG still has its reset parent (XO), so clk_round_rate() returns a bogus rate, which then ends up in the PHY bit clock request and the PLL gets programmed to a wrong frequency, breaking the panel. Move the rounding to dsi_link_clk_set_rate_6g(), which is called after the RCGs have been reparented to the PLL. Storing the rounded rate at this point still makes later link_clk_set_rate() calls no-ops in the CCF. Derive the byte interface clock rate from the rounded byte clock rate, otherwise it would keep requesting the idealized rate and retrigger the PLL on every transfer. Reported-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Fixes: 6cd33b6f4155 ("drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value") Assisted-by: LLM Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # SM6115P J606F Tested-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/750496/ Link: https://lore.kernel.org/r/20260903-fix-eliza-dsi-v1-1-3474a6c9f2e0@oss.qualcomm.com
2026-09-14wifi: ath11k: cleanup arsta in ath11k_mac_peer_cleanup_all()Nicolas Escande1-7/+18
When mac80211 removes a sta, it calls .sta_state() which in turn calls ath11k_mac_station_remove(). In that function we clean up both peers & arsta related resources. But when the firmware crashes, ath11k calls ieee80211_restart_hw(), which assumes that all driver related resources are cleaned up beforehand. This cleanup is supposedly done by ath11k_mac_peer_cleanup_all() but does not in fact free arsta->rx_stats / tx_stats. Extract the arsta cleanup from ath11k_mac_station_remove() into a new ath11k_mac_station_cleanup() and call it from both there and ath11k_mac_peer_cleanup_all(). This should handle kmemleaks reports like: unreferenced object 0xffffff801ae66400 (size 1024): comm "hostapd", pid 1306, jiffies 4295011565 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc d61c08ec): kmemleak_alloc+0x3c/0x50 __kmalloc_cache_noprof+0x2b0/0x3e0 ath11k_mac_op_sta_state+0x1dc/0xb10 drv_sta_state+0xac/0x6f8 sta_info_insert_rcu+0x314/0x5e0 sta_info_insert+0x14/0x38 ieee80211_add_station+0x10c/0x1a0 nl80211_new_station+0x3e8/0x680 genl_family_rcv_msg_doit+0xc0/0x120 genl_rcv_msg+0x1b4/0x258 netlink_rcv_skb+0x4c/0x108 genl_rcv+0x38/0x60 netlink_unicast+0x190/0x278 netlink_sendmsg+0x15c/0x370 ____sys_sendmsg+0x120/0x290 ___sys_sendmsg+0x70/0xa0 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Nicolas Escande <nico.escande@gmail.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260731145830.769811-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-09-14wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardownFan Wu1-1/+1
wcn36xx_dxe_deinit() tears down the TX ack timer with timer_delete(), which only dequeues the timer and does not wait for a callback that is already executing; the preceding free_irq() calls synchronize the interrupt handlers only. The callback, wcn36xx_dxe_tx_timer(), can therefore be running past the teardown and use the wcn freed along with the ieee80211_hw in wcn36xx_remove(): it takes wcn->dxe_lock, reads wcn->tx_ack_skb and passes wcn->hw to ieee80211_tx_status_irqsafe(). Fix this by using timer_shutdown_sync(), which waits for a running callback and also prevents the timer from being rearmed again. The timer is set up again by wcn36xx_dxe_init() on the next start, so the start/stop cycle is unaffected. This issue was found by an in-house static analysis tool. Fixes: fdf21cc37149 ("wcn36xx: Add TX ack support") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Song Li <songl@zju.edu.cn> Signed-off-by: Song Li <songl@zju.edu.cn> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260910020907.3353-1-fanwu01@zju.edu.cn Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-09-14wifi: ath12k: ahb: Revert undocumented ABI and dead codeKrzysztof Kozlowski1-50/+1
Commit 96f46607bbce ("wifi: ath12k: add AHB platform descriptor support") added undocumented OF ABI, by relying on a very specific node name. This is not allowed and was never acked by Devicetree maintainers. Additionally that part of code is not even used, because all devices have exactly the same user pd, so this was added "for future". Adding dead code just "for future" is heavily discouraged in kernel coding. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260825081313.71351-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-09-14Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaLinus Torvalds35-128/+239
Pull rdma fixes from Jason Gunthorpe: "Lots of bug fixes from the last weeks: - Various error unwind bugs - Several more races and bugs in siw and rxe, including remote triggerable - HFI1 corruption with its credit scheme - Remove a bogus user triggerable dev_warn - Lock __ethtool_get_link_ksettings() properly - Fix a lockdep loop with diassociation - Several storage related bugs, some triggerable remotely - Do no leak physical addresses to userspace in bnxt_re - Fix wrong irq context for the xarrays in erdma - User triggerable race in ucma with multicast - Race in ipoib with multicast flushing and destruction" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: (28 commits) RDMA/siw: Bound fragmented header copies by the remaining length RDMA/efa: Keep EQ resources alive while IRQ is registered RDMA/efa: Keep admin queues alive while IRQ is registered RDMA/core: fix refcount bug in iwpm_get_nlmsg_request() IB/IPoIB: Avoid restoring OPER_UP after multicast flush RDMA/ucma: Serialize join and leave on copy_to_user failure RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted RDMA/irdma: Enforce local fence for IB_WR_REG_MR RDMA/erdma: Use IRQ-safe XArray helpers for QP and CQ tables RDMA/mad: Fix receive buffer leak when PKey enforcement fails RDMA/uverbs: Fix potential leak of resources->collection in flow_resources_alloc() RDMA/bnxt_re: Avoid exposing umdbr to userspace RDMA/rtrs: guard against null kobj name RDMA/bnxt_re: check create_singlethread_workqueue() in DCB setup IB/isert: wait for deferred control PDU completions before releasing the connection IB/iser: reject a remote invalidation of an unregistered direction RDMA/srp: Fix srp_remove_target() IB/mlx4: Fix use-after-free on pkey sysfs registration failure RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency RDMA/core: Reject unregistering netdevs in ib_get_eth_speed ...
2026-09-14HID: bpf: fix __hid_bpf_hw_check_params report lengthBenjamin Tissoires1-4/+8
Turns out that USB, I2C and other transport drivers (except uhid which just passes the data) still need to have the report ID in the first byte. Because they expect the first byte to be the report ID or 0, when the report ID is 0, they strip that first byte before forwarding to the device. This means that the transport layer forwards a buffer of size N-1 to the device, which gets rejected. Fixes: 5599f8019661 ("HID: bpf: export hid_hw_output_report as a BPF kfunc") Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-09-14hwmon: (w83793) release probe data through krefGuangshuo Li1-1/+3
w83793_probe() initializes data->kref to manage the lifetime of the driver data. The normal remove path drops the driver-owned reference with kref_put(), while watchdog users take and release additional references through the same kref. However, the probe error path still frees data directly with kfree(). This bypasses the kref-managed lifetime and discards the initial reference without a matching kref_put(), leaving the reference accounting unbalanced. Drop the probe-owned reference with kref_put() instead and let w83793_release_resources() perform the final free, matching the normal remove path. This issue was found by manual code inspection. Fixes: 5852f9609d21 ("hwmon: (w83793) Add watchdog functionality") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Link: https://patch.msgid.link/20260914073638.1662500-1-lgs201920130244@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-09-14hwmon: (w83791d) remove fan/pwm 4-5 sysfs group on removeGuangshuo Li1-0/+1
When the fan/pwm 4-5 pins are not used as GPIO, w83791d_probe() creates the w83791d_group_fanpwm45 sysfs group on the I2C client device. The probe error path removes this group when a later initialization step fails, but the normal remove path only removes w83791d_group. As a result, the optional fan/pwm 4-5 sysfs files can remain after the driver is unbound. The callbacks associated with these files access the driver data, which is devm allocated and released after driver unbind. Leaving the sysfs files behind can therefore result in accesses to stale driver data. Remove w83791d_group_fanpwm45 during normal teardown as well. This issue was found by manual code inspection. Fixes: 6e1ecd9b8f13 ("hwmon: (w83791d) fan 4/5 pins can also be used for gpio") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Link: https://patch.msgid.link/20260914062809.1650538-1-lgs201920130244@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-09-14hwmon: (gpio-fan) return IRQ_HANDLED from the shared alarm IRQ handlerCong Nguyen1-2/+2
fan_alarm_irq_handler() always schedules alarm_work but returns IRQ_NONE, so the kernel treats every alarm interrupt as unhandled. On a shared line that risks the whole line being disabled as spurious. v1 just fixed that, but it was still IRQF_SHARED, and always returning IRQ_HANDLED there defeats spurious-interrupt detection for the line -- if the interrupt ever fires without a real event, nothing catches it, and a fault could spin the CPU in the handler. Sashiko flagged this in v1, and Guenter confirmed: this interrupt must not be shared. So v2 drops IRQF_SHARED too. Fixes: d6fe1360f42e ("hwmon: add generic GPIO fan driver") Reported-by: Sashiko AI review <sashiko-bot@kernel.org> Link: https://lore.kernel.org/r/20260901160931.DD3811F00A3D@smtp.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen <congnt264@gmail.com> Link: https://patch.msgid.link/20260914104136.1797979-1-congnt264@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-09-14drm/vc4: Use managed KMS polling to fix UAF on unbindKarl Mehltretter1-1/+1
vc4_kms_load() calls drm_kms_helper_poll_init() but the driver provides no matching drm_kms_helper_poll_fini(). The output poll work stays scheduled after unbind and runs on the freed drm_device: # modprobe vc4; rmmod vc4; sleep 10 BUG: KASAN: slab-use-after-free in delayed_work_timer_fn BUG: KASAN: slab-use-after-free in drm_client_dev_hotplug [drm] Workqueue: events output_poll_execute [drm_kms_helper] Allocated by task 171: __devm_drm_dev_alloc Freed by task 262 (rmmod): drm_dev_put / component_del Use drmm_kms_helper_poll_init() so polling is finalized with the device, as other drivers do. Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Link: https://patch.msgid.link/20260822143110.68594-1-kmehltretter@gmail.com Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-09-14Merge tag 'scmi-ffa-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixesArnd Bergmann4-7/+16
Arm firmware fixes for v7.3 SCPI fixes address resource leaks and invalid firmware responses, while FF-A gains shutdown cleanup needed for normal kexec. - Release the device node reference acquired during SCPI domain lookup. - Validate SCPI DVFS OPP counts and indices returned by firmware to prevent out-of-bounds accesses and invalid clock rates. - Register the SCPI cpufreq device only once across DVFS providers, preserving the registered device pointer for cleanup and allowing retries after registration failure. - Run FF-A teardown during orderly shutdown so notifications, partition devices and RX/TX mappings are released before a replacement kernel boots through normal kexec. Also includes replacing a literal platform device ID with PLATFORM_DEVID_NONE and correcting an SCMI comment typo. * tag 'scmi-ffa-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Fix typo "upto" in comment firmware: arm_ffa: Tear down driver during shutdown clk: scpi: use PLATFORM_DEVID_NONE for scpi-cpufreq clk: scpi: register scpi-cpufreq once and clear on failure clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS firmware: arm_scpi: fix device_node leak in scpi_dev_domain_id Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-09-14mtd: spi-nor: core: Fix mutex leak in spi_nor_rww_start_exclusive()Runyu Xiao1-1/+1
Use the same guard(mutex) pattern as the other RWW helpers so nor->lock is released on both the busy and successful return paths. Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> [mw: rephrased commit message] Signed-off-by: Michael Walle <mwalle@kernel.org>
2026-09-14drm/xe/shrinker: Take a runtime PM ref before shrinking non-system memoryShuicheng Lin1-27/+51
__xe_shrinker_walk() walks the SYSTEM and TT LRUs without a runtime PM reference. Shrinking a bo outside system memory invalidates its GPU mappings, which needs the device resumed, so while it is runtime suspended the page table zap trips an assert and the TLB invalidation returns -ENODEV: WARNING: drivers/gpu/drm/xe/xe_bo.c:770 at xe_bo_move_notify+0x1fc/0x450 [xe] xe_bo_shrink+0x20f/0x2b0 [xe] __xe_shrinker_walk+0x174/0x410 [xe] xe_shrinker_scan+0x10c/0x1e0 [xe] do_shrink_slab+0x176/0x7e0 drop_caches_sysctl_handler+0x9c/0xf0 Take a reference before walking a memory type other than XE_PL_SYSTEM and stop there if it cannot be acquired. Reuse the shrinker's existing acquire path, which resumes the device directly where reclaim allows that and otherwise queues the PM worker for a later scan. Stop the walk once the scan target is met, so a satisfied scan does not wake the device. System memory is still reclaimed while the device is suspended. Gate this on xe_device_is_l2_flush_optimized(), the same condition under which xe_bo_trigger_rebind() issues the invalidation for a non-fault-mode vm, so reclaim is unaffected elsewhere. The System CCS copy already has its own reference in xe_bo_shrink(). Only a non-fault-mode vm can reach this, since a fault-mode vm requires LR mode and that holds a runtime PM reference for the vm's lifetime. Reproduced with igt@xe_madvise@dontneed-before-exec while the GPU is runtime suspended. v2: simplify needs_rpm check. (Matt) retarget Fixes tag since the issue occurs with the non-fault-mode path added by 4e7ebff69aed. v3: handle this in xe_shrinker.c instead of xe_bo.c (Thomas) v4: stop the walk once the scan target is met. (Sashiko) v5: rebase on the freed page accounting fix. (Sashiko) v6: reuse the shrinker acquire path so runtime pm can be resumed directly instead of always queueing a worker. (Thomas) v7: replace xe_pm_runtime_put() with xe_shrinker_runtime_pm_put(). (Thomas) Fixes: 4e7ebff69aed ("drm/xe/xe3p_lpg: flush shrinker bo cachelines manually") Assisted-by: Claude:claude-opus-5 Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260909162102.1097006-3-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> (cherry picked from commit 628f92b28bf4c371c10207daf6fc4caee0c0db2e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-09-14drm/xe/shrinker: Return the freed page count through a parameterShuicheng Lin1-36/+26
__xe_shrinker_walk() and xe_shrinker_walk() return either the number of pages freed or a negative error, so the two cannot be reported at once. On error the pages already freed are dropped, and since xe_shrinker_scan() only accumulates non-negative returns while *scanned is updated by pointer, the shrinker tells mm that it scanned without freeing. Accumulate the count into a caller-provided counter and return only the status, so an error no longer discards what the walk had freed. Fixes: 00c8efc3180f ("drm/xe: Add a shrinker for xe bos") Assisted-by: Claude:claude-opus-5 Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260909162102.1097006-2-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> (cherry picked from commit d7aac1a0235a6ce41e30cec385e2db8c33dad12d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-09-14drm/xe/mmio_gem: fix destroy flowIlia Levi1-7/+35
xe_mmio_gem_destroy() currently frees the GEM object directly, bypassing reference counting. Since existing VMAs hold a reference and the fault handler accesses the object through vma->vm_private_data, this is use-after-free. Additionally, nothing prevents the fault handler from installing PTEs to the real MMIO after destroy. Fix this with proper synchronization and refcounting. Also, do not set vm_pgoff to zero. Many DRM drivers do this because helpers like dma_mmap_pages() interpret vm_pgoff as an intra-buffer page offset; leaving the DRM fake offset there would break these helpers. Those drivers can get away with zeroing it because they map eagerly - all PTEs are established before mmap returns, so vm_pgoff is never consulted again. Our driver does not use such helpers and the newly introduced call to drm_vma_node_unmap() relies on vm_pgoff being untouched. v2: (Matt Auld) - use dma_resv lock to serialize fault handler with destroy - SIGBUS on access after destroy Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-16-matthew.auld@intel.com (cherry picked from commit fb2ee38bab8025ad6a7a9cbb4635c5a178e4a7bc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-09-14drm/xe/mmio_gem: cache the dummy page per objectIlia Levi1-11/+16
Currently, when the fault handler provides a dummy page, it allocates a new one on every invocation and ties its lifetime to the drm_device via drmm_add_action_or_reset(). Concurrent faults after hot-unplug therefore accumulate pages that persist until device teardown. Cache a single dummy page in the xe_mmio_gem object and use dma_resv lock to protect its allocation. Free it with the object. v2: use dma_resv lock to protect the allocation (Matt Auld) Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-15-matthew.auld@intel.com (cherry picked from commit 8bf6213f9831e46313af4722a1ee6db1b7596378) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-09-14drm/xe/mmio_gem: Revoke drm_vma_node on xe_mmio_gem destroyShuicheng Lin2-2/+4
xe_mmio_gem_create() calls drm_vma_node_allow() but nothing ever calls drm_vma_node_revoke(). The drm_vma_offset_file rb-tree entry allocated by drm_vma_node_allow() is not freed by drm_gem_object_release(), so it is leaked on every create/destroy cycle. Add a struct drm_file * parameter to xe_mmio_gem_destroy() and call drm_vma_node_revoke() from there, mirroring the drm_vma_node_allow() call in xe_mmio_gem_create(). Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Suggested-by: Ilia Levi <ilia.levi@intel.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Ilia Levi <ilia.levi@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-14-matthew.auld@intel.com (cherry picked from commit 32f0cb250598456d812fb7ca57a040282858323d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-09-14drm/xe/mmio_gem: simplify fault handler loopIlia Levi1-6/+6
Make the iteration over the addresses in the VMA more explicit. No functional change, as the VMA matches the GEM object exactly. Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-13-matthew.auld@intel.com (cherry picked from commit 6666ca9192f3bdf839aad33b9e1c9ebb7a222a29) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-09-14drm/xe/mmio_gem: use write-back mapping for dummy pageIlia Levi1-14/+5
Currently vmf_insert_pfn() maps the dummy page as UC, inheriting the VMA's page protection which was set for the real MMIO region. This conflicts with the direct map's WB mapping of the same page, creating a cache type alias which is architecturally undefined on some platforms. Use vmf_insert_pfn_prot() with a WB pgprot instead. Also simplify to fault in the requested page instead of the whole VMA. Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260525125801.975038-6-ilia.levi%40intel.com Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-12-matthew.auld@intel.com (cherry picked from commit 1e8e28e35df0e77ae1b22fc091c1f422f62fa5e9) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-09-14drm/xe/mmio_gem: forbid VMA splitIlia Levi1-0/+10
The fault handler assumes it always operates on a VMA spanning the entire GEM object. This does not hold when the VMA has been split, e.g. by a partial munmap or mprotect. In that case the handler may map wrong physical pages or cause SIGBUS. Handle this by forbidding VMA split, as partial unmaps are not deemed useful for MMIO GEMs. Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Ilia Levi <ilia.levi@intel.com> Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-11-matthew.auld@intel.com (cherry picked from commit f3391a0b12d7bf826a0b21600d2f294f3dce4c14) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-09-14wifi: libipw: reject TKIP frames without a full MICDaehyeon Ko1-5/+7
libipw_michael_mic_verify() assumes that an skb contains an eight-byte Michael MIC. A short TKIP frame makes the unsigned payload length wrap, causing michael_mic() to read past the skb. Check that the MIC is present before verifying it, and use the existing MICHAEL_MIC_LEN constant for all MIC lengths in the verifier. Fixes: b453872c35cf ("[NET] ieee80211 subsystem") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/20260909061124.3802517-1-4ncienth@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-14wifi: virt_wifi: don't transfer operstate before registerZihan Xi1-1/+2
virt_wifi_newlink() calls netif_stacked_transfer_operstate() before register_netdevice(). If the lower device is dormant, that queues the new netdev on lweventlist while it is still uninitialized. If registration fails after that, for example because of an invalid name such as "bad/name", free_netdev() immediately frees the object. A later linkwatch_fire_event() then use-after-frees the list entry. Move the transfer to after netdev_upper_dev_link(), as macvlan and ipvlan already do. Fixes: c7cdba31ed8b ("mac80211-next: rtnetlink wifi simulation device") Reported-by: Vega <vega@nebusec.ai> Assisted-by: LLM Co-developed-by: Luxing Yin <root@tr0jan.top> Signed-off-by: Luxing Yin <root@tr0jan.top> Signed-off-by: Zihan Xi <zihanx@nebusec.ai> Link: https://patch.msgid.link/f5a832fb0ab228ce6e2b5a91fba4ca8b79198a2f.1788948455.git.zihanx@nebusec.ai Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-14HID: amd_sfh: Validate PCI BAR size before mappingSlawomir Stepien2-0/+14
The amd_sfh driver maps PCI BAR 2 using pcim_iomap_regions() and subsequently accesses MMIO registers at offsets up to 0x10958 (e.g., AMD_P2C_MSG3 at 0x1068C). However, the driver never validates that the BAR size is large enough to cover these accesses. If the driver is bound to a device with a smaller BAR 2, this leads to an out-of-bounds memory access and a page fault during the probe function. For example, a page fault can occur when reading from privdata->mmio + AMD_P2C_MSG3 in mp2_select_ops(): BUG: unable to handle page fault for address: ffffc9000390368c PGD 100000067 P4D 100000067 PUD 1012c1067 PMD 105b64067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline] RIP: 0010:mp2_select_ops drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:282 [inline] RIP: 0010:amd_mp2_pci_probe+0x337/0x5f0 drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:487 Call Trace: <TASK> local_pci_probe drivers/pci/pci-driver.c:332 [inline] pci_call_probe drivers/pci/pci-driver.c:394 [inline] __pci_device_probe drivers/pci/pci-driver.c:455 [inline] pci_device_probe+0x431/0xc90 drivers/pci/pci-driver.c:489 Fix this by verifying that the length of BAR 2 is at least 128KB before attempting to map it. Since the maximum accessed offset is 0x10958, and PCI BAR sizes are powers of 2, any legitimate hardware will have a BAR size of at least 128KB. Fixes: 4f567b9f8141 ("SFH: PCIe driver to add support of AMD sensor fusion hub") Assisted-by: Gemini:gemini-3.7-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+4eadd4dfe9e66522bae8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4eadd4dfe9e66522bae8 Link: https://syzkaller.appspot.com/ai_job?id=3bc1c45c-548f-4ab5-8243-d2c8ec321d6c Signed-off-by: Slawomir Stepien <sst@poczta.fm> Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Link: https://syzkaller.appspot.com/bug?extid=4eadd4dfe9e66522bae8 Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-09-14mmc: sdhci-of-aspeed: Remove children before releasing SDC resourcesMyeonghun Pak1-1/+4
Probe failure and removal leave SDHCI child devices registered after the parent clock and managed resources are released. Unregister the OF children in reverse order before disabling the parent clock on both paths. Use of_platform_device_destroy() because manual child creation does not set the flag required by of_platform_depopulate(). This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: bb7b8ec62dfb ("mmc: sdhci-of-aspeed: Add support for the ASPEED SD controller") Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Assisted-by: OpenAI:GPT-5.6 Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-14pinctrl: mpfs-mssio: use correct regmap function to set bank voltageConor Dooley1-2/+2
regmap_assign_bits() is not the correct function to use for an RMW operation, as it maps to regmap_set_bits() or regmap_clear_bits() and the former will never zero a bit. Use regmap_update_bits() instead, which will actually set the bank voltages to what have been requested. CC: stable@vger.kernel.org Fixes: 488d704ed7b7 ("pinctrl: add polarfire soc mssio pinctrl driver") Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-09-14pinctrl: mpfs-mssio: fix width of unused bank voltage settingConor Dooley1-1/+1
The bank voltages are only 4 bits wide, so when a pin was unused the driver was not correctly interpreting it as being at zero volts, because the driver's value for unused had two extra set bits. CC: stable@vger.kernel.org Fixes: 488d704ed7b7 ("pinctrl: add polarfire soc mssio pinctrl driver") Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-09-14pinctrl: generic: serialise pinctrl_generic_dt_node_to_map()Sarah Emery1-0/+4
pinctrl_generic_add_group() documents that the caller must take care of locking, and pinmux_generic_add_function() needs it too, but pinctrl_generic_dt_node_to_map() calls them without holding pctldev->mutex, and the core caller in create_pinctrl() does not take it either. The driver core calls pinctrl_bind_pins() before probing a device, so two devices that reference the same pin controller can run pinctrl_generic_dt_node_to_map() on one pctldev at the same time. Both `add` functions take the new selector from pctldev->num_groups or pctldev->num_functions, and radix_tree_insert() at that index. Two racing callers can read the same selector before either has inserted, so the second insert collides and fails: k1-pinctrl d401e000.pinctrl: error -EEXIST: error adding function pcie2-0-cfg k1-pinctrl d401e000.pinctrl: does not have pin group pcie0-0-cfg.pcie0-0-pins leaving one consumer without its pin configuration. This was hit on a SpacemiT K3 board, where PCIe devices probe in parallel against the single shared pin controller. Take pctldev->mutex across the whole function, so that the groups and the function referring are in a single critical section. Fixes: 43722575e5cd ("pinctrl: add generic functions + pins mapper") Signed-off-by: Sarah Emery <sarah.emery@canonical.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-09-14gpio: virtuser: skip free_irq when no IRQ is installedRunyu Xiao1-1/+2
Disabling interrupt monitoring uses atomic_xchg() to clear the stored IRQ. When monitoring is already disabled, atomic_xchg() returns 0. It must not be passed to free_irq(). The bug is reproducible on an x86_64 QEMU guest with CONFIG_GPIO_VIRTUSER=y and CONFIG_GPIO_SIM=y. Configure a live gpio-virtuser device through configfs. Its input lookup must refer to a live gpio-sim bank, such as key gpio-sim-test with offset 0. The consumer's dev_name attribute is shown as <dev> below; then run: echo 0 > /sys/kernel/debug/gpio-virtuser/<dev>/gpiod:input:0/interrupts On an unpatched kernel, this reaches gpio_virtuser_interrupts_set() with ld->irq still at its initial value 0, and free_irq() reports: Trying to free already-free IRQ 0 The same reproducer completes without the warning on the patched kernel. Fixes: 91581c4b3f29 ("gpio: virtuser: new virtual testing driver for the GPIO API") Assisted-by: LLM Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260914051537.15320-1-runyu.xiao@seu.edu.cn Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-09-14pinctrl: meson: Fix typo in s4 group nameSean Anderson1-1/+1
One of the i2c pin groups has some junk at the end. The name should be i2c2_scl_h1, and indeed that's the name used by i2c2_pins3 in meson-s4.dtsi. Fixes: 775214d389c25 ("pinctrl: meson: add pinctrl driver support for Meson-S4 Soc") Signed-off-by: Sean Anderson <sanderson@brivo.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-09-14power: sequencing: fix NULL-pointer dereference in pwrseq_device_register()Bartosz Golaszewski1-4/+4
If dev_set_name() fails in pwrseq_device_register(), we jump to the err_put_pwrseq label before initializing pwrseq->targets. pwrseq_release() will try to iterate over targets unconditionally and subsequently dereference an invalid pointer. Move the call to dev_set_name() after the list head is initialized. Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Cc: stable@vger.kernel.org Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260903-pwrseq-kunit-v1-0-1f893d2cabc2%40oss.qualcomm.com?part=2 Link: https://patch.msgid.link/20260909-pwrseq-kunit-v2-3-ef496afc89d2@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-09-14power: sequencing: fix NULL-pointer dereference in pwrseq_unit_new()Bartosz Golaszewski1-0/+1
If memory allocation fails in pwrseq_unit_setup_deps(), pwrseq_unit_put() is called to release the partially initialized unit. However, we've never initialized unit->list and pwrseq_unit_release() will unconditionally call list_del() on it. Initialize unit->list right after allocating the unit struct. Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Cc: stable@vger.kernel.org Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260903-pwrseq-kunit-v1-0-1f893d2cabc2%40oss.qualcomm.com?part=1 Link: https://patch.msgid.link/20260909-pwrseq-kunit-v2-2-ef496afc89d2@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-09-14power: sequencing: don't call .post_enable() if pwrseq_unit_enable() failedBartosz Golaszewski1-0/+2
If the call to pwrseq_unit_enable() failed in pwrseq_enable(), bail out instead of calling target->post_enable() which assumes the target was successfully enabled. Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260909-pwrseq-kunit-v2-1-ef496afc89d2@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-09-13hwmon: (pmbus/core) increase number of phases and add new maskNuno Sá1-1/+2
Increase the number of phases to 16 as a new upcoming device supports such a number. While at it, add a new mask for controlling the source of the output voltage. Note (groeck): This patch was meant to prepare for support of MAX20826 and compatible devices, which support more than 10 phases per page. However, Sashiko reports that the mp2975 driver already supports up to 14 phases, and the mp2856 driver supports up to 12 phases. This already has the potential for out-of-bounds writes when probing the affected chips, making this patch a bug fix. Fixes: 2c6fcbb21149 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2975 controller") Fixes: f9e5f289b686 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2856/mp2857 controller") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20260911-hwmon-max20826-support-v2-1-5e30cbd97d84@analog.com Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-09-13hwmon: (cgbc-hwmon) Add missing sensorsThomas Richard (congatec GmbH)1-18/+34
Add the following sensors: - Alternate Board Temperature (temp11_input) - Top DIMM 1-7 Temperature (temp12_input to temp18_input) - Bottom DIMM 1 Temperature (temp19_input) - 12V Standby Voltage (in14_input) This fixes the following warning on conga-SA7: Board Controller returned an unknown sensor (bc_type=1, bc_id=11), ignore it Also update existing labels to match Congatec documentation. Cc: stable@kernel.org Fixes: 08ebc9def79f ("hwmon: Add Congatec Board Controller monitoring driver") Signed-off-by: Thomas Richard (congatec GmbH) <thomas.richard@bootlin.com> Link: https://patch.msgid.link/20260911-cgbc-hwmon-fix-and-new-sensors-v2-2-0c6bf078d173@bootlin.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-09-13hwmon: (cgbc-hwmon) Fix current sensors ID lookupThomas Richard (congatec GmbH)1-39/+54
Current sensors on the Congatec Board Controller don't use consecutive IDs, unlike other sensor types (voltage, temperature, fan). The driver assumed consecutive IDs and performed a simple lookup, which caused an unknown sensor warning. Define current sensor IDs explicitly. Changes the warning on conga-SA7 (type and channel are correct now). Before: Board Controller returned an unknown sensor (type=2, channel=17), ignore it After: Board Controller returned an unknown sensor (bc_type=1, bc_id=11), ignore it Cc: stable@kernel.org Fixes: 08ebc9def79f ("hwmon: Add Congatec Board Controller monitoring driver") Signed-off-by: Thomas Richard (congatec GmbH) <thomas.richard@bootlin.com> Link: https://patch.msgid.link/20260911-cgbc-hwmon-fix-and-new-sensors-v2-1-0c6bf078d173@bootlin.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-09-13hwmon: (pwm-fan) Stop RPM timer before freeing tach dataYibo Tan1-1/+12
sample_timer() rearms the RPM timer and accesses the devm-managed ctx->tachs and ctx->pulses_per_revolution arrays. The cleanup action which stops the timer is registered before those arrays are allocated. Since devres releases entries in reverse order, driver detach can free the arrays before pwm_fan_cleanup() shuts down the timer. A timer expiry in that window accesses the freed tach data. With a KASAN kernel, a test-only kprobe delayed entry to pwm_fan_cleanup() while normal sysfs unbind ran. Each of three runs reported three four-byte reads and two four-byte writes in sample_timer() after its backing devm allocations had been freed. The helper did not invoke the timer callback, cleanup actions or free functions. With the fix, three matching unbind runs completed without KASAN, BUG, WARNING, Oops or panic. Instrumentation confirmed that timer retirement completed before the first timer backing allocation was released. Split timer retirement from the power cleanup and register its devres action after the timer backing data and IRQ actions are installed. This preserves the early power rollback action while ensuring the timer is retired before its backing data is released. Use timer_shutdown_sync() because the callback can rearm itself. Fixes: 01695410d452 ("hwmon: (pwm-fan) Store tach data separately") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Yibo Tan <lhfff@tju.edu.cn> Link: https://patch.msgid.link/20260911071809.130151-1-lhfff@tju.edu.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-09-13hwmon: (k10temp) Fix model id range of Zen5 TurinRong Zhang1-1/+1
Model 20h-2Fh are mobile processors with single CCD. For example, model 24h is Strix Point, i.e., Ryzen AI 7 (PRO) (H/HX) 360/365/370. Including mobile processors in the model id range of Zen5 Turin processors leads to bogus reporting: k10temp-pci-00c3 Adapter: PCI adapter Tctl: +54.1°C Tccd4: +148.6°C Tccd6: +148.4°C Tccd7: +149.1°C Tccd8: +149.2°C Tccd9: +149.2°C Tccd12: +149.1°C Tccd14: +22.0°C Tccd15: +22.0°C Tccd16: +22.0°C Fix it by removing the said range. Fixes: 8440d5aca227 ("hwmon: (k10temp) Add per-CCD temperature monitoring for Zen5 Turin") Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260911-k10temp-fix-zen5-epyc-v1-1-643f5a248ae1@rong.moe Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-09-13Input: hp_sdc - shut down kicker timer on module exitRunyu Xiao1-1/+1
hp_sdc_kicker() rearms hp_sdc.kicker with mod_timer() after scheduling the tasklet. The module exit path uses timer_delete_sync(). That waits for a callback already running but can still leave the timer rearmed. A callback can therefore leave the timer pending while hp_sdc_exit() tears down the driver, allowing timer activity to access dismantled driver state. Use timer_shutdown_sync() for final teardown. It waits for a running callback and prevents rearming after module exit begins. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Acked-by: Helge Deller <deller@gmx.de> Link: https://patch.msgid.link/20260902154004.3595416-1-runyu.xiao@seu.edu.cn Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-13Input: xpad - add support for Victrix Pro BFG ControllerErich Sartison1-0/+1
The controller doesn't currently work via USB-cable. Signed-off-by: Erich Sartison <byt.es@mailbox.org> Link: https://patch.msgid.link/20260903103137.630170-1-byt.es@mailbox.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-13Input: tsc2007 - read "ti,poll-period" as u32Rob Herring (Arm)1-3/+2
The "ti,poll-period" property is documented as a normal uint32 cell. The driver used a u64 helper, which makes the helper type disagree with the schema even though the stored value is still small. Read "ti,poll-period" with the u32 helper matching the documented DT cell size. Assisted-by: Codex:gpt-5-5 Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260831194352.1185860-1-robh@kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-13Input: eeti_ts - publish the OF module aliashpp.iscas1-0/+1
The EETI driver matches eeti,exc3000-i2c Device Tree clients, but only publishes the legacy eeti_ts I2C ID. The I2C core emits an OF modalias for a Device Tree client. Publish the existing OF match table within its CONFIG_OF guard. Fixes: e32d7f1b246c ("Input: eeti - add device tree matching table") Signed-off-by: hpp.iscas <hppiscas@163.com> Link: https://patch.msgid.link/20260905134004.66336-1-hppiscas@163.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-13Input: xpad - add support for Azeron devicesRoberts Kursitis1-0/+7
Azeron controllers (Cyro, Cyborg, Classic/Compact, Cyro Lefty, Cyborg II and Keyzen) present a standard Xbox 360 controller interface, so they work with the existing xpad driver once their USB IDs are added. The 0x16d0 vendor ID is a shared block, but this is safe because xpad only binds interfaces that match the Xbox 360 signature. Tested with an Azeron Keyzen. Signed-off-by: Roberts Kursitis <roberts.kursitis@azeron.eu> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260906143040.162418-1-roberts.kursitis@azeron.eu Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-13Input: xpad - fix PDP Marvel Xbox 360 controllerJeremy Nyberg1-1/+1
The PDP Marvel Xbox 360 controller with USB ID 0e6f:0147 is incorrectly classified as an Xbox One controller. With the current XTYPE_XBOXONE classification, the controller is detected but produces no input, while its four player LEDs continue blinking indefinitely. Classify USB ID 0e6f:0147 as an Xbox 360 controller instead. Tested on a PDP Marvel Xbox 360 controller with USB ID 0e6f:0147. All inputs register correctly and the player LED indicates the current player. Fixes: c225370e01b8 ("Input: xpad - sync supported devices with 360Controller") Cc: stable@vger.kernel.org Signed-off-by: Jeremy Nyberg <SlickStretch3.0@gmail.com> Link: https://patch.msgid.link/20260910071627.236014-1-SlickStretch3.0@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-13Input: soc_button_array - check btns_desc->package.countHans de Goede1-1/+1
Check that btns_desc->package.count is not 0 before accessing btns_desc->package.elements[0]. Fixes: 4c3362f44980 ("Input: soc_button_array - add support for ACPI 6.0 Generic Button Device") Cc: stable@vger.kernel.org Reported-by: Shashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/linux-input/20260909091440.3384C1F00A3A@smtp.kernel.org/ Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260909093934.29411-2-johannes.goede@oss.qualcomm.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-13Input: soc_button_array - fix MS Surface Pro 11 probe failureHans de Goede1-3/+11
On the MS Surface Pro 11 soc_button_array probing races with the GPIO driver probing. If soc_button_array wins the race then gpiod_get() returns EPROBE_DEFER, which should normally take care of retrying later, but the soc_button_array code deliberately ignores EPROBE_DEFER causing it to fail its probe() which causes the volume and power buttons to now work. The ignoring of EPROBE_DEFER is there to deal with a problem specific to older Bay Trail (BYT) and Cherry Trail (CHT) tablets which often use this driver. Modify the error handling to only ignore EPROBE_DEFER on BYT and CHT platforms and propagate EPROBE_DEFER normally on other platforms. Fixes: bcf059578980 ("Input: soc_button_array - partial revert of support for newer surface devices") Cc: stable@vger.kernel.org Reported-by: Sergey Lebedev <lsa.uz@pm.me> Closes: https://lore.kernel.org/lkml/20260830141355.55898-1-lsa.uz@pm.me/ Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Tested-by: Sergey Lebedev <lsa.uz@pm.me> Link: https://patch.msgid.link/20260909093934.29411-1-johannes.goede@oss.qualcomm.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-14spi: spi-qpic-snand: avoid writing QPIC_EBI2_ECC_BUF_CFG registerGabor Juhos1-4/+0
The description of commit bfb34eced559 ("mtd: rawnand: qcom: avoid writing to obsolete register") says this: "QPIC_EBI2_ECC_BUF_CFG register got obsolete from QPIC V2.0 onwards. Avoid writing this register if QPIC version is V2.0 or newer." Although the referenced commit is related to the 'qcom-nandc' driver, however the hardware supported by the current driver is also based on QPIC v2.0 so we should avoid writing that register here as well. Remove the register writing code to avoid undefined behaviour. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Md Sadre Alam <md.alam@oss.qualcomm.com> Link: https://patch.msgid.link/20260909-qpic-snand-avoid-ebi2-reg-write-v1-1-9b1b1466cc75@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-09-13Input: i8042 - add quirk for Acer Aspire Go 15 AG15-42PChris Sommers1-0/+7
On the Acer Aspire Go 15 (AG15-42P), the internal keyboard drops out ~5 seconds after boot on both Linux and Linux-LTS kernels. Keystrokes on the built-in keyboard stop registering while the trackpad and external keyboards remain functional. Testing confirms that booting with the i8042.reset kernel parameter resolves the issue and keeps the internal keyboard responsive. Add SERIO_QUIRK_RESET_ALWAYS to i8042_dmi_quirk_table for the Acer Aspire AG15-42P to automatically apply this quirk on boot. Signed-off-by: Chris Sommers <chris.sommers@icloud.com> Link: https://patch.msgid.link/20260907182723.2709981-1-chris.sommers@icloud.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-13Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)Raphaël Larocque1-0/+8
The Lenovo ThinkPad T440p (PNP ID LEN0036, board id 2722) has a Synaptics touchpad whose SMBus companion is not ready at boot and takes roughly 200 seconds to appear. During this window the touchpad and TrackPoint are completely unresponsive on approximately 50% of boots, making the machine unusable until the companion finally registers. The device is in the topbuttonpad_pnp_ids[] SMBus allowlist, so the kernel attempts to use SMBus/RMI4 mode by default. When the companion is not ready, psmouse_smbus_init() leaves breadcrumbs and returns -EAGAIN, the PS/2 fallback path is taken, but the device does not function properly until the companion appears and RMI4 takes over. Disable SMBus InterTouch for board id 2722 so the touchpad and TrackPoint work immediately via PS/2 from boot. Users can still force SMBus with psmouse.synaptics_intertouch=1 if needed. Tested-by: Raphaël Larocque <rlarocque@disroot.org> Signed-off-by: Raphaël Larocque <rlarocque@disroot.org> Link: https://patch.msgid.link/20260910164425.12832-1-rlarocque@disroot.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-14drm/msm/dpu: clear pending peripheral flush stateSaim Shujah1-0/+1
dpu_hw_ctl_clear_pending_flush() resets the cached per-block state after a flush transaction, but misses pending_periph_flush_mask. The peripheral flush updater accumulates interface bits in this mask. A later transaction which sets the top-level peripheral flush bit can write stale interface bits to CTL_PERIPH_FLUSH together with the current state. Peripheral flush support was added after the helper started clearing every individual pending flush mask. Clear the peripheral mask together with the other cached child masks. Fixes: 64f7b81f0358 ("drm/msm/dpu: add support of new peripheral flush mechanism") Cc: stable@vger.kernel.org Signed-off-by: Saim Shujah <saimzst@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/748968/ Link: https://lore.kernel.org/r/20260828065440.140410-1-saimzst@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>