summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-07-27spi: ppc4xx: devm-ify probe and drop manual resource managementRosen Penev1-75/+22
Replace open-coded resource handling with devm helpers: - spi_alloc_host -> devm_spi_alloc_host - of_address_to_resource + ioremap + request_mem_region -> devm_platform_ioremap_resource - request_irq -> devm_request_irq - remove now-unused mapbase/mapsize fields from struct ppc4xx_spi - move of_node_put(opbnp) earlier to simplify error paths - delete the entire error-unwinding goto chain Move devm_platform_ioremap_resource() and platform_get_irq() up in order to avoid doing work if -EPROBE_DEFER is returned. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260720003043.1536358-1-rosenp@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27spi: oc-tiny: switch to managed controller allocationFan Wu1-16/+8
The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded driver-private devdata, which is the IRQ handler's dev_id. The devm_request_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach tiny_spi_irq() and dereference already-freed memory (e.g. hw->base). Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. This issue was found by an in-house static analysis tool. Fixes: ce792580ea2c ("spi: add OpenCores tiny SPI driver") Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Link: https://patch.msgid.link/20260719010014.3163356-1-fanwu01@zju.edu.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27spi: spi-qpic-snand: Increase ECC strength for large OOB SPI-NAND devicesMd Sadre Alam1-0/+13
Some SPI-NAND devices with large OOB areas require a stronger ECC configuration than the default one provided through firmware description. For example, Macronix devices with a 256-byte OOB area report that 4-bit ECC is insufficient and trigger: nand: WARNING: the ECC used on your system is too weak compared to the one required by the NAND chip The QPIC SPI-NAND controller supports both 4-bit and 8-bit BCH ECC modes. When a device exposes an OOB area of at least 128 bytes, there is sufficient space to accommodate 8-bit ECC without exceeding the OOB layout constraints. Automatically increase the ECC strength to 8 bits when the detected OOB size is 128 bytes or larger and the current configuration requests a weaker ECC level. This avoids ECC capability mismatches on devices that require stronger error correction and improves reliability. Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com> Link: https://patch.msgid.link/20260716-8bitecc-v1-1-6eef4bcc3a14@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27clk: mediatek: mt6735: Unregister PLLs on probe failureMyeonghun Pak1-1/+4
mtk_clk_register_plls() registers the apmixedsys PLL clocks manually, while clk_mt6735_apmixed_remove() unregisters them on driver removal. If devm_of_clk_add_hw_provider() fails after the PLL registration succeeds, probe returns the error directly and the remove callback is not run. This leaves the registered PLL clocks behind on the probe failure path. Unregister the PLLs in that failure branch before returning the error. Fixes: 43c04ed79189 ("clk: mediatek: Add drivers for MediaTek MT6735 main clock and reset drivers") Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-27ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev()Ming Lei1-0/+9
ublk_ctrl_add_dev() memcpy()s the userspace ublksrv_ctrl_dev_info into ub->dev_info and then fixes up the fields the driver owns, but misses ->state and ->ublksrv_pid. A device added with ->state = UBLK_S_DEV_LIVE passes the "->state != UBLK_S_DEV_DEAD" test that ublk_stop_dev_unlocked() uses as its proxy for "a disk is attached", while ->ub_disk is still NULL, so DEL_DEV right after ADD_DEV oopses in del_gendisk(). UBLK_S_DEV_QUIESCED plus UBLK_F_USER_RECOVERY dies one step earlier, in ublk_force_abort_dev(). A poisoned ->state also gets START_USER_RECOVERY and the char device read/write path onto a device that was never started, and wedges START_DEV at -EEXIST. A poisoned ->ublksrv_pid just makes GET_DEV_INFO report an unrelated task as the ublk server. Reset both after the memcpy(), as ublk_detach_disk() does. Userspace only ever reads these back, so correcting them silently breaks nothing. ADD_DEV has copied ->state in unsanitized since ublk was merged, but back then it was harmless: the gendisk was allocated during ADD_DEV, and both teardown and the START_DEV -EEXIST check keyed off disk_live() rather than ->state. The oops became reachable once the disk allocation moved to START_DEV and those checks switched to ->state. Fixes: 6d9e6dfdf3b2 ("ublk: defer disk allocation") Cc: stable@vger.kernel.org Signed-off-by: Ming Lei <tom.leiming@gmail.com> Reviewed-by: Caleb Sander Mateos <csander@purestorage.com> Link: https://patch.msgid.link/20260726145025.1507383-1-tom.leiming@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-27drm/nouveau/kms/nv50-: Unconditionally create blend_mode prop for wndwsLyude Paul1-7/+11
Since the commit mentioned down below, it looks like we've been triggering this WARN_ON(): [ 31.477009] ------------[ cut here ]------------ [ 31.477012] [PLANE:66:curs-0] pixel format with alpha exposed but blend mode not setup [ 31.477014] WARNING: drivers/gpu/drm/drm_mode_config.c:872 at drm_mode_config_validate+0x38c/0x4c0, CPU#1: modprobe/1264 [ 31.477125] CPU: 1 UID: 0 PID: 1264 Comm: modprobe Not tainted 7.2.0-rc2Lyude-Test+ #1 PREEMPT(lazy) [ 31.477129] Hardware name: Micro-Star International Co., Ltd. MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.M4 05/10/2023 [ 31.477132] RIP: 0010:drm_mode_config_validate+0x394/0x4c0 [ 31.477136] Code: 41 3b 9e 80 00 00 00 73 bd 49 8b 46 78 8b 3c 98 e8 c1 3d ff ff 80 78 14 00 74 e1 48 8d 3d 64 e6 e7 01 49 8b 56 18 41 8b 76 50 <67> 48 0f b9 3a 49 8b 46 08 4c 8d 70 f8 49 39 c5 75 97 8b 95 b8 02 [ 31.477139] RSP: 0018:ffffd48e053bb7f8 EFLAGS: 00010202 [ 31.477143] RAX: ffffffffaf1da9c0 RBX: 0000000000000000 RCX: 0000000000000034 [ 31.477145] RDX: ffff8cd883c1feb0 RSI: 0000000000000042 RDI: ffffffffb069f840 [ 31.477148] RBP: ffff8cd88ea3d800 R08: 0000000034325241 R09: ffff8cd88ea3dac0 [ 31.477150] R10: fffffaf5c4043600 R11: ffff8cd88004f600 R12: 0000000000000001 [ 31.477152] R13: ffff8cd88ea3da90 R14: ffff8cd88b9ec038 R15: ffff8cd88ea3dab0 [ 31.477154] FS: 00007fb934898780(0000) GS:ffff8cd9f3a6a000(0000) knlGS:0000000000000000 [ 31.477157] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 31.477160] CR2: 0000555efff79520 CR3: 0000000122cd5000 CR4: 00000000003506f0 [ 31.477162] Call Trace: [ 31.477165] <TASK> [ 31.477168] ? nouveau_hwmon_init+0x2d6/0x330 [nouveau] [ 31.477346] drm_dev_register+0x19d/0x270 [ 31.477352] nouveau_drm_device_init+0x17a/0x230 [nouveau] [ 31.477523] nouveau_drm_probe+0x13d/0x1e0 [nouveau] [ 31.477690] local_pci_probe+0x3e/0x90 [ 31.477697] pci_call_probe+0x59/0x190 [ 31.477702] ? srso_return_thunk+0x5/0x5f [ 31.477706] ? pci_match_device+0x15a/0x180 [ 31.477710] ? pci_assign_irq+0x2d/0x160 [ 31.477714] pci_device_probe+0x95/0x160 [ 31.477719] call_driver_probe+0x26/0x100 [ 31.477724] ? driver_sysfs_add+0x59/0xd0 [ 31.477738] really_probe+0xcc/0x2c0 [ 31.477743] ? srso_return_thunk+0x5/0x5f [ 31.477749] __driver_probe_device+0x85/0x170 [ 31.477754] driver_probe_device+0x1f/0x90 [ 31.477760] ? __pfx___driver_attach+0x10/0x10 [ 31.477766] __driver_attach+0xcb/0x210 [ 31.477772] bus_for_each_dev+0x85/0xd0 [ 31.477779] bus_add_driver+0x13e/0x220 [ 31.477786] ? __pfx_init_module+0x10/0x10 [nouveau] [ 31.477979] driver_register+0x75/0xe0 [ 31.477984] ? srso_return_thunk+0x5/0x5f [ 31.477990] nouveau_drm_init+0x8b/0xff0 [nouveau] [ 31.478192] do_one_initcall+0x5d/0x300 [ 31.478204] do_init_module+0x86/0x290 [ 31.478212] init_module_from_file+0xd8/0x140 [ 31.478223] idempotent_init_module+0x114/0x310 [ 31.478233] __x64_sys_finit_module+0x71/0xe0 [ 31.478238] do_syscall_64+0xe2/0x630 [ 31.478252] ? srso_return_thunk+0x5/0x5f [ 31.478257] ? vfs_read+0x165/0x390 [ 31.478267] ? srso_return_thunk+0x5/0x5f [ 31.478271] ? srso_return_thunk+0x5/0x5f [ 31.478276] ? switch_fpu_return+0x52/0xe0 [ 31.478282] ? srso_return_thunk+0x5/0x5f [ 31.478286] ? arch_exit_to_user_mode_prepare.isra.0+0x7e/0x90 [ 31.478292] ? srso_return_thunk+0x5/0x5f [ 31.478296] ? do_syscall_64+0x11f/0x630 [ 31.478301] ? srso_return_thunk+0x5/0x5f [ 31.478305] ? arch_exit_to_user_mode_prepare.isra.0+0x7e/0x90 [ 31.478310] ? srso_return_thunk+0x5/0x5f [ 31.478314] ? do_syscall_64+0x11f/0x630 [ 31.478320] ? srso_return_thunk+0x5/0x5f [ 31.478324] ? arch_exit_to_user_mode_prepare.isra.0+0x7e/0x90 [ 31.478329] ? srso_return_thunk+0x5/0x5f [ 31.478334] ? srso_return_thunk+0x5/0x5f [ 31.478338] ? do_syscall_64+0x99/0x630 [ 31.478343] ? exc_page_fault+0x82/0x1c0 [ 31.478350] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 31.478355] RIP: 0033:0x7fb93410030d [ 31.478372] 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 c3 5a 0f 00 f7 d8 64 89 01 48 [ 31.478375] RSP: 002b:00007ffc587ce738 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 31.478381] RAX: ffffffffffffffda RBX: 0000562f5fb3da60 RCX: 00007fb93410030d [ 31.478385] RDX: 0000000000000000 RSI: 0000562f5fb40590 RDI: 000000000000000d [ 31.478388] RBP: 00007ffc587ce7d0 R08: 0000000000000000 R09: 0000000000000000 [ 31.478391] R10: 0000000000000000 R11: 0000000000000246 R12: 0000562f5fb40590 [ 31.478394] R13: 0000000000040000 R14: 0000562f5fb3db80 R15: 0000000000000009 [ 31.478404] </TASK> [ 31.478407] ---[ end trace 0000000000000000 ]--- Fix it by making sure we unconditionally call drm_plane_create_blend_mode_property for all types of wndws, including those (such as cursors) without a blend_set function. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260720215058.398210-4-lyude@redhat.com
2026-07-27drm/nouveau/kms/nv50-: Introduce nv50_wndw_default_state()Lyude Paul3-0/+27
While we don't currently read-in the hardware state of planes, now that we're about to start exposing blend properties for all planes that can support alpha channels: We need to make sure that the initial atomic state for a wndw always starts off with a supported value in pixel_blend_mode. The easiest way to do this is to introduce a nv50_wndw_default_state() function, and use it in nv50_display_read_hw_state() - and use that function to enforce a valid value for pixel_blend_mode during driver startup. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Link: https://patch.msgid.link/20260720215058.398210-3-lyude@redhat.com
2026-07-27drm/nouveau/kms/nv50-: Add .blend_modes to nv50_wndw_funcLyude Paul10-0/+26
At the moment, we currently (incorrectly) only expose a blend property on the plane if we have a nv50_wndw_func->blend_set function for the given wndw type. But we need to expose a blend property for all types of planes that can display color formats with an alpha channel. Prepare for doing this by introducing a way of looking up the supported blend modes for a type of wndw by introducing .blend_modes, which describes all possible blending modes nouveau currently supports for a type of wndw. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Link: https://patch.msgid.link/20260720215058.398210-2-lyude@redhat.com
2026-07-27PCI/pwrctrl: tc9563: Power off only the external ports in ↵Manivannan Sadhasivam1-2/+8
tc9563_pwrctrl_disable_port() TC9563 supports powering off only the external facing ports like DSP1 and DSP2. It is not recommended to power off USP and DSP3 as they have fixed ports/endpoint connected. Fix tc9563_pwrctrl_disable_port() to power off only DSP1 and DSP2. Fixes: 4c9c7be47310 ("PCI: pwrctrl: Add power control driver for TC9563") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Elder <elder@riscstar.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260725-tc9563-fix-v1-3-ec4286e31331@oss.qualcomm.com
2026-07-27PCI/pwrctrl: tc9563: Fix parsing the integrated Ethernet MAC Endpoint nodeManivannan Sadhasivam1-4/+10
DSP3 has an integrated Ethernet MAC Endpoint which has its own set of config registers for configuring settings such as ASPM. The Endpoint device has two physical functions and those two functions share the same settings. Parse the Endpoint node under DSP3 instead of parsing both functions. The existing parsing logic also has one OOB issue as parsing both functions will result in accessing past the tc9563_pwrctrl->cfg array. Fixes: 4c9c7be47310 ("PCI: pwrctrl: Add power control driver for TC9563") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Elder <elder@riscstar.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260725-tc9563-fix-v1-2-ec4286e31331@oss.qualcomm.com
2026-07-27mmc: omap_hsmmc: use platform_get_irq_optional for wake IRQRosen Penev1-4/+7
Replace irq_of_parse_and_map() with platform_get_irq_optional() to get the wake IRQ. This is a more portable approach that works with both DT and non-DT platforms, and follows the modern platform API conventions for optional IRQ resources. The wake IRQ is now fetched earlier in the probe function alongside the main IRQ, and the -EPROBE_DEFER case is handled properly before the deferred probe can be triggered. Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-27mmc: via-sdmmc: cancel card-detect work on removeFan Wu1-0/+4
Disabling the device interrupt and freeing the IRQ prevents new card-detect work from being queued, but carddet_work already queued by the handler can still run after via_sd_remove() returns. via_sdc_card_detect() recovers the host through container_of() and dereferences its MMIO base; once remove() returns the host can be freed, so that work would touch freed memory. Cancel carddet_work after freeing the IRQ and before cancelling finish_bh_work, which the card-detect handler can also queue. carddet_work can re-enable the interrupt through via_reset_pcictrl(); mask it again afterwards. This issue was found by an in-house static analysis tool and confirmed by manual code review. Fixes: f0bf7f61b840 ("mmc: Add new via-sdmmc host controller driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-27mmc: via-sdmmc: stop card-detect handling on probe failureFan Wu1-1/+7
request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review. Fixes: e4e46fb61e3b ("mmc: via-sdmmc: fix return value check of mmc_add_host()") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-27Merge tag 'pinctrl-v7.2-2' of ↵Linus Torvalds5-16/+22
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "The most interesting commit is the S4 fix for AMD, which probably is helpful to a whole bunch of important machines. - Wakeup nits on the Qualcomm SC8280XP - Double-free issues on the device tree parsing error path - Fixup of the S4 sleep state handling on AMD pin control - Missing Kconfig select REGMAP_MMIO for the Microchip driver leading to compile stalls - Missing Kconfig select GENERIC_PINCONF for the Bitmain BM1880 leading to compile stalls" * tag 'pinctrl-v7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: bm1880: add missing select GENERIC_PINCONF pinctrl-amd: Don't clear S4 wake bits at probe pinctrl: microchip-sgpio: add missing select REGMAP_MMIO pinctrl: devicetree: don't free uninitialized dev_name on error path pinctrl: qcom: sc8280xp: Add missing wakeup entries for GPIO143/151 pinctrl: qcom: Unconditionally mark gpio as wakeup enable
2026-07-27drm/vmwgfx: validate external BO copy bounds for both stride pathsZack Rusin1-8/+31
vmw_external_bo_copy() trusts caller-supplied offsets, strides, and heights and operates on imported dma-buf vmaps: - The equal-stride memcpy() bound was clamped after subtracting the offsets from dst_size and src_size; an offset larger than the BO size wraps the unsigned subtraction to a huge value and the resulting memcpy() runs off the end of the vmap. dst_stride * height is also a u32 multiplication that can overflow. - The non-equal-stride row-by-row path had no bound at all. The loop touches bytes through offset + (height - 1) * stride + width_in_bytes, with only a WARN_ON(dst_stride < width_in_bytes), and could likewise step past the end of either mapping. The offsets and strides are derived from STDU/SOU plane state, so a configured CRTC submitting a crafted atomic commit on an imported framebuffer can reach this path. Validate the exact row-copy endpoint against each BO's size up front using check_mul_overflow() and check_add_overflow(). Use the bulk memcpy() path only when width_in_bytes covers the whole stride; otherwise copy one row at a time so partial-row updates near the bottom of a framebuffer remain valid. Also reject zero strides and stride < width_in_bytes, both of which the row-by-row path cannot represent safely. Fixes: 50f119925091 ("drm/vmwgfx: Fix prime with external buffers") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-13-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: use check_add_overflow for shader size+offset boundZack Rusin1-4/+9
vmw_shader_define() validates the user-supplied shader window against its backing buffer with (u64)buffer->tbo.base.size < (u64)size + (u64)offset drm_vmw_shader_create_arg::offset is __u64 in the uapi; when it is near U64_MAX the unsigned addition wraps and the resulting tiny value passes the check. The unbounded offset is then stored in res->guest_memory_offset and forwarded to host SVGA shader-create commands. Use check_add_overflow() to detect the wrap and compare the resulting endpoint against the buffer size. Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-12-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: skip hash_del_rcu when validation context has no hash tableZack Rusin1-1/+2
vmw_validation_add_resource() calls hash_add_rcu() only when ctx->sw_context is non-NULL, but the doomed-resource error path calls hash_del_rcu() unconditionally. The validation contexts declared with DECLARE_VAL_CONTEXT(_, NULL, 0) in vmwgfx_kms.c, vmwgfx_scrn.c, vmwgfx_stdu.c and vmwgfx_execbuf.c consequently reach a delete for a node that was never added to any hash chain. That is harmless today, but only incidentally so. hash_del_rcu() is hlist_del_init_rcu(), which is guarded by hlist_unhashed(), and vmw_validation_mem_alloc() hands out memory from __GFP_ZERO pages that are never recycled within a context's lifetime, so node->hash.head.pprev is always NULL and the delete does nothing. Neither property is apparent at the call site, and the asymmetry with the add side invites a real bug the first time either one changes. Mirror the condition from the add side so the node is only unlinked when it was actually linked. No functional change. Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-11-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: enforce cursor size limits for MOB cursorsZack Rusin1-5/+44
vmw_cursor_plane_atomic_check() bounds cursor width and height only on the legacy update path; the SVGA_CAP2_CURSOR_MOB path -- the default on modern hosts -- accepts any size. When the requested size exceeds SVGA_REG_CURSOR_MAX_DIMENSION or SVGA_REG_MOB_MAX_SIZE, vmw_cursor_mob_get() returns -EINVAL and leaves vps->cursor.mob NULL. Its return value is then discarded in vmw_cursor_plane_prepare_fb(), so the subsequent vmw_cursor_update_mob() calls vmw_bo_map_and_cache(NULL) and oopses inside vmw_bo_map_and_cache_size() on the tbo.base.size load. Reachable from any DRM master via DRM_IOCTL_MODE_CURSOR2 with a sufficiently large width or height (e.g. cursor_max_dim + 1). Reject oversized cursors in atomic_check for both MOB-backed cursor update types. The MOB byte-size limit only applies to the SVGA_CAP2_CURSOR_MOB path (vmw_cursor_mob_size() returns 0 for GB_ONLY); compute the required MOB size in 64-bit to avoid overflow when very large dimensions are requested. In prepare_fb only call vmw_cursor_mob_get()/_map() for VMW_CURSOR_UPDATE_MOB -- the GB_ONLY path uses bo->map.virtual directly and would otherwise be silently downgraded to NONE on hosts without SVGA_CAP2_CURSOR_MOB (where vmw_cursor_mob_get() always returns -EINVAL). Degrade the update to NONE if vmw_cursor_mob_get() or vmw_cursor_mob_map() fails so the update path does not run with a NULL backing MOB. Fixes: 965544150d1c ("drm/vmwgfx: Refactor cursor handling") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-10-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failureZack Rusin1-8/+9
Two paths through vmw_vkms_init() can leave vmw->crc_workq NULL while still leaving the rest of the driver in a state that calls vmw_vkms_cleanup() at module unload: 1. vmw_host_get_guestinfo(GUESTINFO_VBLANK, ...) failing or returning an oversized buffer -- the common case on hosts without a VBLANK guestinfo entry -- early-returned before the workqueue allocation. 2. alloc_ordered_workqueue() returning NULL on memory pressure. vmw_vkms_cleanup() then calls destroy_workqueue(NULL), which dereferences wq->name and panics. Fix the first case by removing the early return: vmw->vkms_enabled is already false on the rpci-failure path so no work will ever be queued, and allocating the workqueue unconditionally keeps the control flow simple. Fix the second case by guarding the cleanup with a NULL check, since alloc_ordered_workqueue() can still fail under low memory. Fixes: 7b0062036c3b ("drm/vmwgfx: Implement virtual crc generation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-9-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: bound DMA command body size against suffix pointerZack Rusin1-0/+6
vmw_cmd_dma() locates the DMA suffix at (unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit. Fixes: 4e4ddd477743 ("drm/vmwgfx: Fix queries if no dma buffer thrashing is occuring.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-8-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: validate DRAW_PRIMITIVES header size before divisionZack Rusin1-1/+7
vmw_cmd_draw() computes maxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front. Fixes: 7a73ba7469cb ("drm/vmwgfx: Use TTM handles instead of SIDs as user-space surface handles.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-7-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: drop dma_buf reference on foreign-fd prime importZack Rusin1-2/+5
ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped. Fixes: 65981f7681ab ("drm/ttm: Add a minimal prime implementation for ttm base objects") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-6-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: take fman->lock around fence list mutation in fifo_downZack Rusin1-1/+12
vmw_fence_fifo_down() drops fman->lock to wait on a fence and, on timeout, mutates fman->fence_list via list_del_init() and signals the fence without re-acquiring the lock. __vmw_fences_update() walks and removes entries from the same list under fman->lock from any other waiter, the fence-IRQ thread, or vmw_fences_update(), so the unlocked list_del_init() can corrupt the list head. Re-take fman->lock before manipulating fence->head and use dma_fence_signal_locked(). Wrap the locked signalling in dma_fence_begin_signalling() / dma_fence_end_signalling() so the lockdep annotation that dma_fence_signal() previously provided is preserved (the same pattern as __vmw_fences_update()). dma_fence_put() is moved outside the lock to avoid a recursive acquire from vmw_fence_obj_destroy(), which also takes fman->lock. Fixes: ae2a104058e2 ("vmwgfx: Implement fence objects") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-5-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: clamp dirty-page range with min, not maxZack Rusin1-2/+2
vmw_bo_dirty_transfer_to_res() and vmw_bo_dirty_clear() compute the intersection of a resource's page range with the BO's tracked dirty range, but clamp res_end against dirty->end with max() instead of min(). When dirty->end exceeds the resource end, the loop walks past the resource's pages, calls vmw_resource_dirty_update() for ranges owned by other resources sharing the same backing MOB and clears their pending dirty bits via bitmap_clear(). The result is silent loss of writeback for unrelated resources whenever two resources share a MOB. Use min() in both functions so the loop is bounded to the intersection of the resource and dirty ranges. Fixes: b7468b15d271 ("drm/vmwgfx: Implement an infrastructure for write-coherent resources") Fixes: 965544150d1c ("drm/vmwgfx: Refactor cursor handling") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-4-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: reject DX_BIND_QUERY without a DX contextZack Rusin1-1/+5
vmw_cmd_dx_bind_query() unconditionally dereferences sw_context->dx_ctx_node->ctx. Userspace can trigger a NULL pointer dereference from any render-node fd by submitting an execbuf with dx_context_handle == SVGA3D_INVALID_ID and a SVGA_3D_CMD_DX_BIND_QUERY opcode in the command stream: dx_ctx_node is left NULL and the kernel oopses on the assignment. The same NULL is then re-read in vmw_resources_reserve() via vmw_context_get_dx_query_mob(). All sibling DX handlers fail-close on a missing dx_ctx_node using VMW_GET_CTX_NODE(). Use the same pattern here, returning -EINVAL up front before any relocation state is published. Fixes: 9c079b8ce8bf ("drm/vmwgfx: Adapt execbuf to the new validation api") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-3-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as sizeZack Rusin1-2/+2
Two sites in vmwgfx_resource.c assign boolean literals to res->guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res->guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource's MOB allocation size: - vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true). Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated. Rename both assignments to guest_memory_dirty. Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-2-zack.rusin@broadcom.com
2026-07-27mmc: moxart: use platform helpers for resource and IRQRosen Penev1-19/+10
Replace of_address_to_resource() and the following devm_ioremap_resource() with a single devm_platform_get_and_ioremap_resource() call in moxart_probe(). This requests the register region and maps it once, which is equivalent to the previous devm_ioremap_resource() behavior, and drops the now-redundant separate resource lookup. Similarly replace irq_of_parse_and_map() with platform_get_irq(), which returns a negative errno on failure (including -EPROBE_DEFER) instead of 0, and tighten the error check to irq < 0. Both substitutions are equivalent for a DT-backed platform device. The remaining OF usage (mmc_of_parse() and the of_device_id table) is covered by already-included headers, so linux/of_address.h and linux/of_irq.h are dropped. No functional change; the MMC register window is requested and mapped exactly once, so there is no overlapping region claim. Built for ARM (allmodconfig + CONFIG_MMC_MOXART) with LLVM=1; drivers/mmc/host/moxart-mmc.o compiles cleanly. Assisted-by: opencode:hy3-free Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-27wifi: ath12k: resolve PENDING ML peer ID from MLO_PEER_MAP HTT eventBaochen Qiang6-0/+100
Add ath12k_dp_peer_fixup_peer_id() and call it from the HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP handler. For devices where the firmware allocates the MLD peer ID, this is the point at which all data structures that were left with ATH12K_MLO_PEER_ID_PENDING or ATH12K_MLO_PEER_ID_INVALID get their real ID: - dp_peer->peer_id is updated and the dp_peer is published into dp_hw->dp_peers[]; - every existing dp_link_peer in dp_peer->link_peers[] gets its ml_id set to the same value; - ahsta->ml_peer_id is updated to the same value so peer_assoc, sta_state and cleanup paths see a consistent ID. Devices with host_alloc_ml_id == true also receive the same HTT event, but the firmware-reported ID always matches the host-allocated one and everything has already been populated by ath12k_dp_peer_create(); Skips the helper entirely on those devices. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221039 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260720-ath12k-fw-allocated-ml-peer-id-v2-8-630632758a80@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-27wifi: ath12k: defer dp_peer registration when firmware allocates MLD peer IDBaochen Qiang4-17/+49
For chips with host_alloc_ml_id=true (QCN9274 etc.), the host allocates the MLD peer ID up front; ath12k_dp_peer_create() publishes the dp_peer into dp_hw->dp_peers[] using that ID immediately. WCN7850/QCC2072 does not work that way: the firmware picks the ID and only tells the host afterwards via HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP, so the publication has to be delayed until the event arrives. Introduce ATH12K_MLO_PEER_ID_PENDING (0xFFFE) as a sentinel for "is_mlo, but ID not yet known". On the firmware-allocates path: - ath12k_mac_op_sta_state(NOTEXIST->NONE) skips ath12k_peer_ml_alloc() and stores PENDING in ahsta->ml_peer_id and dp_params.peer_id; - ath12k_dp_peer_create() skips dp_peer registration until a real ID is known; - ath12k_peer_create() leaves peer->ml_id at INVALID so consumer sites do not treat PENDING as a real ID; - ath12k_peer_ml_free() and ath12k_mac_dp_peer_cleanup() skip the dp_peers[] write and the free_ml_peer_id_map clear when host_alloc_ml_id is false or the ID is still PENDING. The HTT handler change that resolves the PENDING ID is added in a follow-up patch. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260720-ath12k-fw-allocated-ml-peer-id-v2-7-630632758a80@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-27wifi: ath12k: do not advertise MLD peer ID for firmware-allocate devicesBaochen Qiang1-4/+18
ath12k_peer_assoc_h_mlo() unconditionally sets ml->peer_id_valid and copies ahsta->ml_peer_id (with the ATH12K_PEER_ML_ID_VALID bookkeeping bit masked off) into the WMI_PEER_ASSOC_CMDID ML params, which causes ath12k_wmi_send_peer_assoc_cmd() to set ATH12K_WMI_FLAG_MLO_PEER_ID_VALID. This needs to be gated on chips where the firmware allocates the MLD peer ID: - WCN7850/QCC2072 firmware always picks the ID itself and does not honor a host-supplied one, so the value would be silently ignored anyway; - QCC2072 firmware additionally crashes during MLO disconnect when ATH12K_WMI_FLAG_MLO_PEER_ID_VALID was set in the preceding peer assoc, so the bit must not be sent at all. Branch on ah->host_alloc_ml_id: - When true (QCN9274 etc.), behavior is unchanged: peer_id_valid is set and the raw ahsta->ml_peer_id (without the VALID bit) is sent down. - When false (WCN7850, QCC2072), peer_id_valid stays unset and ml_peer_id is sent as 0. The firmware ignores both fields and reports the ID it allocated through HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP. The early-return on ahsta->ml_peer_id == ATH12K_MLO_PEER_ID_INVALID only applies on the host-alloc path, since on the firmware-alloc path the value is ATH12K_MLO_PEER_ID_PENDING here, not INVALID. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260720-ath12k-fw-allocated-ml-peer-id-v2-6-630632758a80@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-27wifi: ath12k: introduce host_alloc_ml_id hardware parameterBaochen Qiang4-1/+32
Different ath12k devices diverge on who allocates MLD peer id: WCN7850/QCC2072 have the firmware allocate it and notify the host via HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP event; While others let the host allocate it and pass it down through WMI_PEER_ASSOC_CMDID with ATH12K_WMI_FLAG_MLO_PEER_ID_VALID set. Currently ath12k host allocates this ID and sends it to firmware by default for all devices. This breaks WCN7850/QCC2072, because the host maintained ID may be different from the firmware-allocated one. Consequently data path may fail to find the dp peer and drop some received packets. From user point of view, this results in bugs reported in [1] or the 4-way handshake timeout issue. Add host_alloc_ml_id flag to struct ath12k_hw_params (and a copy on struct ath12k_hw for hot-path access) so subsequent patches can branch on it. Set true for QCN9274/IPQ5332/IPQ5424, false for WCN7850/QCC2072. The flag will be consumed by subsequent patches. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Link: https://bugzilla.kernel.org/show_bug.cgi?id=221039 # 1 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260720-ath12k-fw-allocated-ml-peer-id-v2-5-630632758a80@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-27wifi: ath12k: add support for HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAPBaochen Qiang2-0/+42
Firmware on chips that allocate the MLD peer ID itself (WCN7850 and QCC2072) reports the assignment back to the host through HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP. The message carries the chosen MLD peer id, the MLD MAC address etc. Add the message type, the on-the-wire struct, the field masks and a handler that parses them out. The host-side state update (publishing the dp peer into ath12k_dp_hw::dp_peers[], propagating the ID to ath12k_dp_link_peer::ml_id and ath12k_sta::ml_peer_id) is added in a follow-up patch; Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260720-ath12k-fw-allocated-ml-peer-id-v2-4-630632758a80@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-27wifi: ath12k: keep ATH12K_PEER_ML_ID_VALID set in ath12k_sta::ml_peer_idBaochen Qiang3-17/+28
Several pieces of host bookkeeping for MLD peer IDs encode the same fact in different ways: - ath12k_sta::ml_peer_id stores the raw ID in [0, ATH12K_MAX_MLO_PEERS); - ath12k_dp_peer::peer_id, ath12k_dp_link_peer::ml_id and the index used on ath12k_dp_hw::dp_peers[] always carry the ATH12K_PEER_ML_ID_VALID bit (BIT(13)) when the ID is real; - WMI_MLO_PEER_ASSOC_PARAMS::ml_peer_id sent down to firmware is raw, without the bookkeeping bit. The mismatch leaks into call sites that have to remember to OR the bit in (ath12k_peer_create(), ath12k_mac_op_sta_state()) or remember not to (ath12k_peer_assoc_h_mlo()). Make ath12k_sta::ml_peer_id carry the VALID bit when valid, the same way ath12k_dp_peer::peer_id and ath12k_dp_link_peer::ml_id do: - ath12k_peer_ml_alloc() OR-s the bit in once on the way out; the internal bitmap stays raw [0, ATH12K_MAX_MLO_PEERS); - ath12k_peer_create() and ath12k_mac_op_sta_state() drop the explicit OR; - ath12k_peer_assoc_h_mlo() masks the bit off when populating the WMI ml_peer_id; While there, introduce ath12k_peer_ml_free() to mirror ath12k_peer_ml_alloc(), which helps avoid code duplication. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260720-ath12k-fw-allocated-ml-peer-id-v2-3-630632758a80@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-27wifi: ath12k: factor out peer assoc send-and-wait into a helperBaochen Qiang1-30/+29
ath12k_bss_assoc(), ath12k_mac_station_assoc() and ath12k_sta_rc_update_wk() all open-code the same sequence: reinit the peer_assoc_done completion, send the peer assoc WMI command, then wait for the firmware confirmation event. The reinit_completion() was buried in ath12k_peer_assoc_prepare(), far from the wait_for_completion_timeout() that consumes it, making the reinit/send/wait sequence hard to follow, and the three open-coded copies are easy to get out of sync. Move the sequence into a new helper ath12k_mac_peer_assoc() and call it from all three sites. The reinit, send and wait now live together so the completion's lifecycle is easy to read. While at it, ath12k_sta_rc_update_wk() previously warned but still waited the full timeout when the peer assoc command failed to send. Now a send failure returns immediately and skips the pointless 1 second wait, matching the other two callers. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260720-ath12k-fw-allocated-ml-peer-id-v2-2-630632758a80@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-27wifi: ath12k: fix out-of-bounds clear_bit in ath12k_mac_dp_peer_cleanup()Baochen Qiang1-1/+4
ath12k_mac_dp_peer_cleanup() clears the ML peer ID slot on the free_ml_peer_id_map bitmap by indexing it with dp_peer->peer_id. That is wrong: dp_peer->peer_id for an MLO peer always carries the ATH12K_PEER_ML_ID_VALID bit (BIT(13)), so clear_bit() is invoked with index >= 0x2000, which is far outside the bitmap of ATH12K_MAX_MLO_PEERS (256) bits and corrupts memory adjacent to ah->free_ml_peer_id_map. The intended bitmap entry also never gets cleared, so subsequent ath12k_peer_ml_alloc() calls eventually run out of IDs. The ID without the VALID bit is what ath12k_peer_ml_alloc() returned and is stored in ahsta->ml_peer_id. Use that instead. While there, also reset ahsta->ml_peer_id to ATH12K_MLO_PEER_ID_INVALID so the bitmap and ahsta->ml_peer_id stay in sync. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: ee16dcf573d5 ("wifi: ath12k: Define ath12k_dp_peer structure & APIs for create & delete") Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260720-ath12k-fw-allocated-ml-peer-id-v2-1-630632758a80@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-27cpufreq: powernow-k8: Fix possible memory leak in powernowk8_cpu_init()Abdun Nihaal1-0/+1
The memory allocated for data->powernow_table inside powernow_k8_cpu_init_acpi() or find_psb_table() is not freed in one of the error paths in powernowk8_cpu_init(). Fix that by adding a kfree(). Fixes: 1ff6e97f1d99 ("[CPUFREQ] cpumask: avoid playing with cpus_allowed in powernow-k8.c") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Link: https://patch.msgid.link/20260727093553.98246-1-nihaal@cse.iitm.ac.in Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-27mmc: host: Remove redundant dev_err()/dev_err_probe()Pan Chuang8-33/+10
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_irq() and devm_request_threaded_irq() automatically log detailed error messages on failure. Remove the now-redundant driver-specific dev_err() and dev_err_probe() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-27pinctrl: qcom: ipq9650: fix audio_sec_mclk_in1/out1 group pinsTaceddin Sancak1-2/+2
The audio_sec_mclk_in1 and audio_sec_mclk_out1 groups both list "gpio37", but in the pingroup table those functions are muxed on gpio39, while gpio37 provides the audio_sec_mclk_in0/out0 variants. This makes both functions unusable: selecting them on gpio39 is rejected by the pinmux core because the group is not listed for the function, and selecting them on gpio37 trips the WARN_ON() in msm_pinmux_set_mux() and fails with -EINVAL because that group cannot mux them. Point both groups at gpio39, matching the pingroup table. This also mirrors the primary audio MCLK pair, where the mclk0 and mclk1 variants live on separate pins (gpio53 and gpio51 respectively). Fixes: 3c8e7ba0e399 ("pinctrl: qcom: Introduce IPQ9650 TLMM driver") Assisted-by: Claude:claude-fable-5 Signed-off-by: Taceddin Sancak <ts.solidarity@gmail.com> Acked-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260718002146.698973-1-ts.solidarity@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-27thermal/drivers/imx: Disable clock on runtime resume failureCan Peng1-2/+7
imx_thermal_runtime_resume() enables the thermal clock before powering up the sensor and enabling measurements. If either regmap_write() fails, the function returns with the clock still enabled. This leaves the clock enable count unbalanced after a failed runtime resume. Disable the clock on those failure paths before returning the error. Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support") Cc: stable@vger.kernel.org Signed-off-by: Can Peng <pengcan@kylinos.cn> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260722084909.463437-1-pengcan@kylinos.cn
2026-07-27powercap: intel_rapl_tpmi: Handle PMU registration failure during probeSumeet Pawnikar1-1/+4
intel_rapl_tpmi_probe() invokes rapl_package_add_pmu() but ignores its return value, so a PMU registration failure would leave the driver reporting probe success despite the PMU being absent, with no log trace. Since PMU registration is an optional auxiliary feature for perf energy counters, its failure should not break the primary powercap functionality. Check the return value and log a warning to ensure graceful degradation. Fixes: 963a9ad3c589 ("powercap: intel_rapl_tpmi: Enable PMU support") Signed-off-by: Sumeet Pawnikar <sumeet4linux@gmail.com> [ rjw: Changed the log level of the new message to "info" ] Link: https://patch.msgid.link/20260723172321.5960-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-27pinctrl: qcom: Add irq_get/set_irqchip_state() for msm gpio irqchipMaulik Shah1-0/+39
MPM irqchip monitors the interrupts during SoC sleep state and after wakeup replays the edge interrupt by making it pending at respective irqchip by invoking irq_set_irqchip_state() API. The msm gpio irqchip however do not implement this function making it impossible to replay the gpio interrupt on any MPM irqchip based SoC. Add the missing irq_get/set_irqchip_state() APIs. Implement only IRQCHIP_STATE_PENDING case which MPM irqchip uses. Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Acked-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Navya Malempati <navya.malempati@oss.qualcomm.com> Link: https://patch.msgid.link/20260424-pinctrl_irqchip_states-v1-1-85286f078916@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-27thermal/drivers/qcom-spmi-adc-tm5: Drop IIO_VAL_INT check in adc_tm5_get_tempRakesh Kota1-3/+0
Commit bb21ee31f575 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale") fixed the iio_read_channel_processed_scale to return 0 on success instead of IIO_VAL_INT (1). The existing check in adc_tm5_get_temp() treated a successful return as an error because it expected IIO_VAL_INT. Drop the redundant `ret != IIO_VAL_INT` condition and rely solely on the negative error check. Fixes: bb21ee31f575 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale") Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> Link: https://patch.msgid.link/20260724-adc-tm5-drop-iio-val-int-check-v1-1-0b85a0895dd7@oss.qualcomm.com
2026-07-27thermal/drivers/airoha: Add support for AN7583 Thermal SensorChristian Marangi1-4/+157
Add support for Airoha AN7583 Thermal driver. This apply similar logic on how to read the temperature but totally drop support for the PTP_THERMAL subsystem. PTP_THERMAL subsystem was a way to trigger trip point from hardware by configuring how to read the temperature internally. This subsystem has been totally removed from Airoha AN7583 permitting only to read the temperature. The SoC support up to 3 sensor but the original driver always read the BGA sensor hence it's currently implemented reading only this specific sensor. Reference and values for the other 2 sensor are defined for further implementation if confirmed working. set_thermal_mux() is extended to also address muxing the sensor as AN7583 use a different way to read the temperature from 3 different diode. The EN7581 code is updated to account for these changes. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260702094846.17325-8-ansuelsmth@gmail.com
2026-07-27thermal/drivers/airoha: Generalize get_thermal_ADC and set_mux functionChristian Marangi1-12/+44
In preparation for support of Airoha AN7583, generalize get_thermal_ADC() and set_thermal_mux() with the use of reg_field API. This is to take into account the same logic between the current supported SoC and the new one but with different register address. While at it also further improve some comments and move sleep inside the set_thermal_mux function. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260702094846.17325-6-ansuelsmth@gmail.com
2026-07-27thermal/drivers/airoha: Generalize probe functionChristian Marangi1-27/+75
In preparation for support of Airoha AN7583, generalize the probe function to address for the 2 SoC difference. Implement a match_data struct where it's possible to define a more specific probe and post_probe function and specific thermal ops and pllrg protect value. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260702094846.17325-5-ansuelsmth@gmail.com
2026-07-27thermal/drivers/airoha: Convert to regmap APIChristian Marangi1-32/+45
In preparation for support of Airoha AN7583, convert the driver to regmap API. This is needed as Airoha AN7583 will be based on syscon regmap. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260702094846.17325-4-ansuelsmth@gmail.com
2026-07-27thermal/drivers/airoha: Fix copy paste error for sen internalChristian Marangi1-1/+1
In airoha_thermal_setup_monitor there is a copy paste error on configuring the internval for temp monitor. Fix the error and use the correct mask for the sen interval for the EN7581_TEMPMONCTL2 register. Fixes: 42de37f40e1b ("thermal/drivers: Add support for Airoha EN7581 thermal sensor") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Wayen Yan <win847@gmail.com> Link: https://patch.msgid.link/20260702094846.17325-3-ansuelsmth@gmail.com
2026-07-27thermal/drivers/airoha: Fix copy paste error on clamp_t low tempChristian Marangi1-1/+1
In airoha_thermal_set_trips, there is a copy paste error on clamping the value for the low trip temp point. Fix it to the correct value and actually clamp for the low variable. Fixes: 42de37f40e1b ("thermal/drivers: Add support for Airoha EN7581 thermal sensor") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Wayen Yan <win847@gmail.com> Link: https://patch.msgid.link/20260702094846.17325-2-ansuelsmth@gmail.com
2026-07-27drm/bridge: Use named initializers for arrays of i2c_device_dataUwe Kleine-König (The Capable Hub)26-47/+47
While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. The mentioned robustness is relevant for a planned change to struct i2c_device_id that replaces .driver_data by an anonymous union. While touching all these arrays, unify usage of whitespace in the list terminator and drop trailing commas there. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Acked-by: Douglas Anderson <dianders@chromium.org> # ti-sn65dsi86.c Link: https://patch.msgid.link/9fa3a8e372b7211c06ec885617051f5006227e3a.1784545092.git.u.kleine-koenig@baylibre.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-27ACPI: CPPC: Skip writes to unsupported performance controlsChristian Loehle1-3/+4
MIN_PERF and MAX_PERF are optional CPPC controls. DESIRED_PERF is also optional with CPPC2 when autonomous selection is supported. The cppc-cpufreq target callbacks populate both limits for every request without checking whether the controls are implemented. cppc_set_perf() consequently passes NULL register descriptors to cpc_write(). The writes fail width validation and their return values are ignored, so the failed access paths are repeated on every target request. An autonomous-only platform can take the same path for DESIRED_PERF. Check that each performance control is supported before calling cpc_write(). Fixes: ea3db45ae476 ("cpufreq: cppc: Update MIN_PERF/MAX_PERF in target callbacks") Reviewed-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Christian Loehle <christian.loehle@arm.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20260724104042.1481804-1-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 06:30:00 +0000