summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-03-23drm/xe/pf: Fix use-after-free in migration restoreMichał Winiarski1-0/+2
When an error is returned from xe_sriov_pf_migration_restore_produce(), the data pointer is not set to NULL, which can trigger use-after-free in subsequent .write() calls. Set the pointer to NULL upon error to fix the problem. Fixes: 1ed30397c0b92 ("drm/xe/pf: Add support for encap/decap of bitstream to/from packet") Reported-by: Sebastian Österlund <sebastian.osterlund@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7230 Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260217154118.176902-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 4f53d8c6d23527d734fe3531d08e15cb170a0819) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-23firmware: qcom_scm: don't opencode kmemdupMukesh Ojha1-2/+1
Lets not opencode kmemdup which is reported by coccinelle tool. Fix it using kmemdup. cocci warnings: (new ones prefixed by >>) >> drivers/firmware/qcom/qcom_scm.c:916:11-18: WARNING opportunity for kmemdup Fixes: 8b9d2050cfa0 ("firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource table") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601142144.HvSlBSI9-lkp@intel.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260310140255.2520230-1-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-23thermal: devfreq_cooling: avoid unnecessary kfree of freq_tableAnas Iqbal1-1/+2
dfc->freq_table is only allocated in the non-EM path via devfreq_cooling_gen_tables(). In the EM path, it remains NULL. Avoid calling kfree() unnecessarily when freq_table was never allocated. This resolves a Smatch warning: calling kfree() when 'dfc->freq_table' is always NULL. Signed-off-by: Anas Iqbal <mohd.abd.6602@gmail.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/20260323094018.2264-1-mohd.abd.6602@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-23pinctrl: abx500: Fix type of 'argument' variableYu-Chun Lin1-1/+1
The argument variable is assigned the return value of pinconf_to_config_argument(), which returns a u32. Change its type from enum pin_config_param to unsigned int to correctly store the configuration argument. Fixes: 03b054e9696c ("pinctrl: Pass all configs to driver on pin_config_set()") Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-03-23pinctrl: sunxi: fix gpiochip_lock_as_irq() failure when pinmux is unknownMichal Piekos2-2/+20
Fixes kernel hang during boot due to inability to set up IRQ on AXP313a. The issue is caused by gpiochip_lock_as_irq() which is failing when gpio is in uninitialized state. Solution is to set pinmux to GPIO INPUT in sunxi_pinctrl_irq_request_resources() if it wasn't initialized earlier. Tested on Orange Pi Zero 3. Fixes: 01e10d0272b9 ("pinctrl: sunxi: Implement gpiochip::get_direction()") Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-03-23pinctrl: sunxi: pass down flags to pinctrl routinesAndre Przywara2-10/+15
Recent changes in the Allwinner pinctrl/GPIO IP made us add some quirks, which the new SoCs (A523 family) need to use. We now have a comfortable "flags" field on the per-SoC setup side, to tag those quirks we need, but were translating those flag bits into specific fields for runtime use, in the init routine. Now the newest Allwinner GPIO IP adds even more quirks and exceptions, some of a boolean nature. To avoid inventing various new boolean flags for the runtime struct sunxi_pinctrl, let's just directly pass on the flags variable used by the setup code, so runtime can check for those various quirk bits directly. Rename the "variant" member to "flags", and directly copy the value from the setup code into there. Move the variant masking from the init routine to the functions which actually use the "variant" value. This mostly paves the way for the new A733 IP generation, which needs more quirks to be checked at runtime. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-03-23platform/x86: intel-hid: disable wakeup_mode during hibernationDavid McFarland1-1/+9
Add a freeze handler which clears wakeup_mode. This fixes aborted hibernation on Dell Precision 3880. Wakeup event detected during hibernation, rolling back This system sends power button events during hibernation, even when triggered by software. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218634 Fixes: 0c4cae1bc00d ("PM: hibernate: Avoid missing wakeup events during hibernation") Signed-off-by: David McFarland <corngood@gmail.com> Link: https://patch.msgid.link/20260205231629.1336348-1-corngood@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86: asus-armoury: add support for GZ302EA and GZ302EACMatthew Schwartz1-0/+29
Add TDP data for tablet models GZ302EA and GZ302EAC. Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> Reviewed-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/20260313004939.4103835-1-matthew.schwartz@linux.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86: asus-nb-wmi: add DMI quirk for ASUS ROG Flow Z13-KJP GZ302EACMatthew Schwartz1-1/+1
The ASUS ROG Flow Z13-KJP GZ302EAC model uses sys_vendor name ASUS rather than ASUSTeK COMPUTER INC., but it needs the same folio quirk as the other ROG Flow Z13. To keep things simple, just match on sys_vendor ASUS since it covers both. Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/20260312212246.1608080-1-matthew.schwartz@linux.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86/amd/hsmp: Fix typo in error messageAlok Tiwari1-1/+1
Fix a typo in the HSMP error message where "tmeout" should be "timeout". Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Link: https://patch.msgid.link/20260310125307.700108-1-alok.a.tiwari@oracle.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/olpc: olpc-xo175-ec: Fix overflow error message to print inlenAlok Tiwari1-1/+1
The command length check validates inlen (> 5), but the error message incorrectly printed resp_len. Print inlen so the log reflects the actual command length. Fixes: 0c3d931b3ab9e ("Platform: OLPC: Add XO-1.75 EC driver") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Acked-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260310130138.700687-1-alok.a.tiwari@oracle.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86: lenovo: wmi-gamezone: Drop gz_chain_headNathan Chancellor1-2/+0
The gz_chain_head variable has been unused since the driver's initial addition to the tree. Its use was eliminated between v3 and v4 during development but due to the reference of gz_chain_head's wait_list member, the compiler could not warn that it was unused. After a (tip) commit ("locking/rwsem: Remove the list_head from struct rw_semaphore"), which removed a reference to the variable passed to __RWSEM_INITIALIZER(), certain configurations show an unused variable warning from the Lenovo wmi-gamezone driver: drivers/platform/x86/lenovo/wmi-gamezone.c:34:31: warning: 'gz_chain_head' defined but not used [-Wunused-variable] 34 | static BLOCKING_NOTIFIER_HEAD(gz_chain_head); | ^~~~~~~~~~~~~ include/linux/notifier.h:119:39: note: in definition of macro 'BLOCKING_NOTIFIER_HEAD' 119 | struct blocking_notifier_head name = \ | ^~~~ Remove the variable to prevent the warning from showing up. Fixes: 22024ac5366f ("platform/x86: Add Lenovo Gamezone WMI Driver") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://patch.msgid.link/20260313-lenovo-wmi-gamezone-remove-gz_chain_head-v1-1-ce5231f0c6fa@kernel.org [ij: reorganized the changelog] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86: ISST: Check HWP support before MSR accessLi RongQing1-0/+3
On some systems, HWP can be explicitly disabled in the BIOS settings When HWP is disabled by firmware, the HWP CPUID bit is not set, and attempting to read MSR_PM_ENABLE will result in a General Protection (GP) fault. unchecked MSR access error: RDMSR from 0x770 at rIP: 0xffffffffc33db92e (disable_dynamic_sst_features+0xe/0x50 [isst_tpmi_core]) Call Trace: <TASK> ? ex_handler_msr+0xf6/0x150 ? fixup_exception+0x1ad/0x340 ? gp_try_fixup_and_notify+0x1e/0xb0 ? exc_general_protection+0xc9/0x390 ? terminate_walk+0x64/0x100 ? asm_exc_general_protection+0x22/0x30 ? disable_dynamic_sst_features+0xe/0x50 [isst_tpmi_core] isst_if_def_ioctl+0xece/0x1050 [isst_tpmi_core] ? ioctl_has_perm.constprop.42+0xe0/0x130 isst_if_def_ioctl+0x10d/0x1a0 [isst_if_common] __se_sys_ioctl+0x86/0xc0 do_syscall_64+0x8a/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 RIP: 0033:0x7f36eaef54a7 Add a check for X86_FEATURE_HWP before accessing the MSR. If HWP is not available, return true safely. Fixes: 12a7d2cb811d ("platform/x86: ISST: Add SST-CP support via TPMI") Signed-off-by: Li RongQing <lirongqing@baidu.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20260303074635.2218-1-lirongqing@baidu.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86: hp-wmi: Add support for Omen 16-k0xxx (8A4D)Krishna Chomal1-0/+11
The HP Omen 16-k0xxx (board ID: 8A4D) has the same WMI interface as other Victus S boards, but requires additional quirks for correctly switching thermal profile. Create a new quirk omen_v1_legacy_thermal_params which allows a board to use Omen V1 thermal values, but rely on the older legacy HP_OMEN_EC_THERMAL_PROFILE_OFFSET. Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to the newly added quirk. Testing on board 8A4D confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Tested-by: Qinfeng Wu <qwqgong@gmail.com> Reported-by: Qinfeng Wu <qwqgong@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221150 Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260302073525.71037-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86: hp-wmi: Add support for Omen 16-wf1xxx (8C76)Krishna Chomal1-0/+4
The HP Omen 16-wf1xxx (board ID: 8C76) has the same WMI interface as other Victus S boards, but requires quirks for correctly switching thermal profile (similar to board 8C78). Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to omen_v1_thermal_params. Testing on board 8C76 confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Tested-by: WJ Enderlava <jie7172585@gmail.com> Reported-by: WJ Enderlava <jie7172585@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221149 Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260227154106.226809-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86: hp-wmi: Add Omen 16-xf0xxx (8BCA) supportRaed1-0/+4
The HP Omen 16-xf0xxx board 8BCA uses the same Victus-S fan and thermal WMI path as other recently supported Omen/Victus boards, but it requires Omen v1 thermal profile parameters for correct platform profile behavior. Add board 8BCA to victus_s_thermal_profile_boards[] and map it to omen_v1_thermal_params. Validated on HP Omen 16-xf0xxx (board 8BCA): - /sys/firmware/acpi/platform_profile exposes low-power/balanced/performance - fan RPM reporting works (fan1_input/fan2_input) - manual fan control works through hp-wmi hwmon (pwm1/pwm1_enable) Signed-off-by: Raed <thisisraed@outlook.com> Link: https://patch.msgid.link/20260311131338.965249-1-youaretalkingtoraed@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86: asus-armoury: add support for G614FPDenis Benato1-0/+34
Add TDP data for laptop model G614FP. Signed-off-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/20260309183559.433555-3-denis.benato@linux.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86: asus-armoury: add support for GA503QMDenis Benato1-0/+14
Add TDP data for laptop model GA503QM. Signed-off-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/20260309183559.433555-2-denis.benato@linux.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23cpufreq: conservative: Reset requested_freq on limits changeViresh Kumar3-0/+16
A recently reported issue highlighted that the cached requested_freq is not guaranteed to stay in sync with policy->cur. If the platform changes the actual CPU frequency after the governor sets one (e.g. due to platform-specific frequency scaling) and a re-sync occurs later, policy->cur may diverge from requested_freq. This can lead to incorrect behavior in the conservative governor. For example, the governor may assume the CPU is already running at the maximum frequency and skip further increases even though there is still headroom. Avoid this by resetting the cached requested_freq to policy->cur on detecting a change in policy limits. Reported-by: Lifeng Zheng <zhenglifeng1@huawei.com> Tested-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://lore.kernel.org/all/20260210115458.3493646-1-zhenglifeng1@huawei.com/ Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Cc: All applicable <stable@vger.kernel.org> Link: https://patch.msgid.link/d846a141a98ac0482f20560fcd7525c0f0ec2f30.1773999467.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-23cpufreq: Don't skip cpufreq_frequency_table_cpuinfo()Viresh Kumar2-6/+7
The commit 6db0f533d320 ("cpufreq: preserve freq_table_sorted across suspend/hibernate") unintentionally made a change where cpufreq_frequency_table_cpuinfo() isn't getting called anymore for old policies getting re-initialized. This leads to potentially invalid values of policy->max and policy->cpuinfo_max_freq. Fix the issue by reverting the original commit and adding the condition for just the sorting function. Fixes: 6db0f533d320 ("cpufreq: preserve freq_table_sorted across suspend/hibernate") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 6.19+ <stable@vger.kernel.org> # 6.19+ Link: https://patch.msgid.link/65ba5c45749267c82e8a87af3dc788b37a0b3f48.1773998611.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-23reset: spacemit: k3: Decouple composite reset linesYixun Lan1-24/+36
Instead of grouping several different reset lines into one composite reset, decouple them to individual ones which make it more aligned with underlying hardware. And for DWC USB driver, it will match well with the number of the reset property in the DT bindings. The DWC3 USB host controller in K3 SoC has three reset lines - AHB, VCC, PHY. The PCIe controller also has three reset lines - DBI, Slave, Master. Also three reset lines each for UCIE and RCPU block. As an agreement with maintainer, the reset IDs has been rearranged as contiguous number but keep most part unchanged to avoid break patches which already sent to mailing list. The changes of DT binding header file and reset driver are merged together as one single commit to avoid git-bisect breakage. Fixes: 938ce3b16582 ("reset: spacemit: Add SpacemiT K3 reset driver") Fixes: 216e0a5e98e5 ("dt-bindings: soc: spacemit: Add K3 reset support and IDs") Signed-off-by: Yixun Lan <dlan@kernel.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-23reset: gpio: fix double free in reset_add_gpio_aux_device() error pathGuangshuo Li1-1/+0
When __auxiliary_device_add() fails, reset_add_gpio_aux_device() calls auxiliary_device_uninit(adev). The device release callback reset_gpio_aux_device_release() frees adev, but the current error path then calls kfree(adev) again, causing a double free. Keep kfree(adev) for the auxiliary_device_init() failure path, but avoid freeing adev after auxiliary_device_uninit(). Fixes: 5fc4e4cf7a22 ("reset: gpio: use software nodes to setup the GPIO lookup") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-23ata: libata-transport: remove redundant dynamic sysfs attributesHeiner Kallweit1-71/+42
Use the static sysfs attributes directly, this allows to significantly simplify the code. See attribute_container_add_attrs() for why member grp can be used instead of attrs. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Tested-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-03-23ata: libata-scsi: refactor ata_scsiop_maint_in()Niklas Cassel1-18/+29
ata_scsiop_maint_in() is currently quite confusing to read, because it currently only implements support for the service action REPORT SUPPORTED OPERATION CODES. Thus, when this function is checking for "invalid command format", it is not very clear if it is an invalid command format for the MAINTENANCE IN command itself, or an invalid command format for the (currently one and only) service action/subcommand implemented for this command. Move the service action to a separate function, so it is more clear that the "invalid command format" check is actually specific for the REPORT SUPPORTED OPERATION CODES service action. This also makes it easier and less confusing to add support for additional service actions in the future. Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-03-23media: amphion: Fix race between m2m job_abort and device_runMing Qian1-6/+3
Fix kernel panic caused by race condition where v4l2_m2m_ctx_release() frees m2m_ctx while v4l2_m2m_try_run() is about to call device_run with the same context. Race sequence: v4l2_m2m_try_run(): v4l2_m2m_ctx_release(): lock/unlock v4l2_m2m_cancel_job() job_abort() v4l2_m2m_job_finish() kfree(m2m_ctx) <- frees ctx device_run() <- use-after-free crash at 0x538 Crash trace: Unable to handle kernel read from unreadable memory at virtual address 0000000000000538 v4l2_m2m_try_run+0x78/0x138 v4l2_m2m_device_run_work+0x14/0x20 The amphion vpu driver does not rely on the m2m framework's device_run callback to perform encode/decode operations. Fix the race by preventing m2m framework job scheduling entirely: - Add job_ready callback returning 0 (no jobs ready for m2m framework) - Remove job_abort callback to avoid the race condition Fixes: 3cd084519c6f ("media: amphion: add vpu v4l2 m2m support") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian <ming.qian@oss.nxp.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23media: mediatek: vcodec: fix use-after-free in encoder release pathFan Wu1-0/+9
The fops_vcodec_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->encode_work. This creates a race window where the workqueue handler (mtk_venc_worker) may still be accessing the context memory after it has been freed. Race condition: CPU 0 (release path) CPU 1 (workqueue) --------------------- ------------------ fops_vcodec_release() v4l2_m2m_ctx_release() v4l2_m2m_cancel_job() // waits for m2m job "done" mtk_venc_worker() v4l2_m2m_job_finish() // m2m job "done" // BUT worker still running! // post-job_finish access: other ctx dereferences // UAF if ctx already freed // returns (job "done") kfree(ctx) // ctx freed Root cause: The v4l2_m2m_ctx_release() only waits for the m2m job lifecycle (via TRANS_RUNNING flag), not the workqueue lifecycle. After v4l2_m2m_job_finish() is called, the m2m framework considers the job complete and v4l2_m2m_ctx_release() returns, but the worker function continues executing and may still access ctx. The work is queued during encode operations via: queue_work(ctx->dev->encode_workqueue, &ctx->encode_work) The worker function accesses ctx->m2m_ctx, ctx->dev, and other ctx fields even after calling v4l2_m2m_job_finish(). This vulnerability was confirmed with KASAN by running an instrumented test module that widens the post-job_finish race window. KASAN detected: BUG: KASAN: slab-use-after-free in mtk_venc_worker+0x159/0x180 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12 Workqueue: mtk_vcodec_enc_wq mtk_venc_worker Allocated by task 47: __kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0 Freed by task 47: __kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190 Fix this by calling cancel_work_sync(&ctx->encode_work) before kfree(ctx). This ensures the workqueue handler is both cancelled (if pending) and synchronized (waits for any running handler to complete) before the context is freed. Placement rationale: The fix is placed after v4l2_ctrl_handler_free() and before list_del_init(&ctx->list). At this point, all m2m operations are done (v4l2_m2m_ctx_release() has returned), and we need to ensure the workqueue is synchronized before removing ctx from the list and freeing it. Note: The open error path does NOT need cancel_work_sync() because INIT_WORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during device_run() operations. Fixes: 0934d3759615 ("media: mediatek: vcodec: separate decoder and encoder") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23media: mtk-jpeg: fix use-after-free in release path due to uncancelled workFan Wu1-0/+1
The mtk_jpeg_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->jpeg_work. This creates a race window where the workqueue callback may still be accessing the context memory after it has been freed. Race condition: CPU 0 (release) CPU 1 (workqueue) ---------------- ------------------ close() mtk_jpeg_release() mtk_jpegenc_worker() ctx = work->data // accessing ctx kfree(ctx) // freed! access ctx // UAF! The work is queued via queue_work() during JPEG encode/decode operations (via mtk_jpeg_device_run). If the device is closed while work is pending or running, the work handler will access freed memory. Fix this by calling cancel_work_sync() BEFORE acquiring the mutex. This ordering is critical: if cancel_work_sync() is called after mutex_lock(), and the work handler also tries to acquire the same mutex, it would cause a deadlock. Note: The open error path does NOT need cancel_work_sync() because INIT_WORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during ioctl operations. Fixes: 5fb1c2361e56 ("mtk-jpegenc: add jpeg encode worker interface") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23media: imx-jpeg: Add support for encoder v1 descriptor configurationMing Qian3-2/+55
Support the upgraded JPEG encoder v1 found on i.MX952 SoC. Detect the encoder hardware version via the version register. The v1 encoder uses an expanded descriptor format that allows all encoding parameters, including JPEG quality, to be configured directly in the descriptor. This removes the manual register-based configuration step required by v0 and reduces the interrupt count from two to one per frame. V0 encoding flow: 1. Write quality to registers -> trigger config interrupt 2. Start encoding -> trigger completion interrupt V1 encoding flow: 1. Configure descriptor with all parameters including quality 2. Start encoding -> trigger completion interrupt Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Ming Qian <ming.qian@oss.nxp.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23media: imx-jpeg: Add encoder ops layer for hardware abstractionMing Qian2-9/+58
Introduce mxc_jpeg_enc_ops function pointer structure to abstract encoder configuration differences between hardware versions. Extract the existing two-phase manual configuration into dedicated functions (enter_config_mode/exit_config_mode) for v0 hardware. Add setup_desc callback placeholder for future v1 hardware support which will use descriptor-based configuration. Store the extended sequential mode flag in the context to avoid recalculating it during configuration phases. No functional change. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Ming Qian <ming.qian@oss.nxp.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23media: imx-jpeg: Use devm_pm_runtime_enable() helperMing Qian1-3/+12
Use devm_pm_runtime_enable() to simplify probe and exit paths. No functional change. Signed-off-by: Ming Qian <ming.qian@oss.nxp.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23media: imx-jpeg: Simplify descriptor initialization with memsetMing Qian1-5/+2
Use memset() to zero-initialize desc and cfg_desc structures instead of assigning individual fields to zero. This is cleaner and ensures all descriptor fields are properly initialized. No functional change. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Ming Qian <ming.qian@oss.nxp.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23media: chips-media: wave5: add missing spinlock protection for ↵Ziyi Guo1-0/+3
handle_dynamic_resolution_change() Add spin_lock_irqsave()/spin_unlock_irqrestore() around the handle_dynamic_resolution_change() call in initialize_sequence() to fix the missing lock protection. initialize_sequence() calls handle_dynamic_resolution_change() without holding inst->state_spinlock. However, handle_dynamic_resolution_change() has lockdep_assert_held(&inst->state_spinlock) indicating that callers must hold this lock. Other callers of handle_dynamic_resolution_change() properly acquire the spinlock: - wave5_vpu_dec_finish_decode() - wave5_vpu_dec_device_run() Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Fixes: 9707a6254a8a6b ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23media: chips-media: wave5: add missing spinlock protection for send_eos_event()Ziyi Guo1-1/+10
Add spin_lock_irqsave()/spin_unlock_irqrestore() around send_eos_event() calls in the VB2 buffer queue and streamoff callbacks to fix the missing lock protection. wave5_vpu_dec_buf_queue_dst() and streamoff_output() call send_eos_event() without holding inst->state_spinlock. However, send_eos_event() has lockdep_assert_held(&inst->state_spinlock) indicating that callers must hold this lock. Other callers of send_eos_event() properly acquire the spinlock: - wave5_vpu_dec_finish_decode() acquires lock at line 431 - wave5_vpu_dec_encoder_cmd() acquires lock at line 821 - wave5_vpu_dec_device_run() acquires lock at line 1592 Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Fixes: 9707a6254a8a6b ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23media: chips-media: wave5: fix a potential memory leak in wave5_vdi_init()Haoxiang Li1-0/+1
Add wave5_vdi_free_dma_memory() in the error path of wave5_vdi_init() to prevent a potential memory leak. Fixes: 45d1a2b93277 ("media: chips-media: wave5: Add vpuapi layer") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23platform/x86: barco-p50-gpio: convert to guard() notationDmitry Torokhov1-16/+10
Using guard notation simplifies control flow and makes the code clearer. Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260318-barco-p50-gpio-set-v2-2-c0a4a6416163@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86: barco-p50-gpio: normalize return value of gpio_getDmitry Torokhov1-1/+4
The GPIO get callback is expected to return 0 or 1 (or a negative error code). Ensure that the value returned by p50_gpio_get() is normalized to the [0, 1] range. Fixes: 86ef402d805d606a ("gpiolib: sanitize the return value of gpio_chip::get()") Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260318-barco-p50-gpio-set-v2-1-c0a4a6416163@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23gpio: qixis-fpga: Fix error handling for devm_regmap_init_mmio()Felix Gu1-2/+2
devm_regmap_init_mmio() returns an ERR_PTR() on failure, not NULL. The original code checked for NULL which would never trigger on error, potentially leading to an invalid pointer dereference. Use IS_ERR() and PTR_ERR() to properly handle the error case. Fixes: e88500247dc3 ("gpio: add QIXIS FPGA GPIO controller") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Link: https://patch.msgid.link/20260320-qixis-v1-1-a8efc22e8945@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-03-23gpio: dwapb: reduce allocation to single kzallocRosen Penev1-14/+5
Instead of kzalloc + kcalloc, Combine the two using a flexible array member. Allows using __counted_by for extra runtime analysis. Move counting variable to right after allocation as required by __counted_by. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260320005338.30355-1-rosenp@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-03-23platform/mellanox: nvsw-sn2201: Drop unused includeAndy Shevchenko1-1/+0
This driver includes the legacy header <linux/gpio.h> but does not use any symbols from it. Drop the inclusion. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260320222033.3238317-1-andriy.shevchenko@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/surface: hotplug: Correct inclusion for GPIO APIsAndy Shevchenko1-1/+1
The modern GPIO APIs are available for users via linux/gpio/consumer.h. The linux/gpio.h is legacy header that is subject to remove. Hence replace the latter by the former in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260320221143.3237791-1-andriy.shevchenko@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23drm/xe/xe3p: Skip TD flushTejas Upadhyay1-0/+8
Xe3p has HW ability to do transient display flush so the xe driver can enable this HW feature by default and skip the software TD flush. Bspec: 60002 Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://patch.msgid.link/20260305121902.1892593-10-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-03-23drm/xe/xe3p_lpg: Restrict UAPI to enable L2 flush optimizationTejas Upadhyay4-0/+35
When set, starting xe3p_lpg, the L2 flush optimization feature will control whether L2 is in Persistent or Transient mode through monitoring of media activity. To enable L2 flush optimization include new feature flag GUC_CTL_ENABLE_L2FLUSH_OPT for Novalake platforms when media type is detected. Tighten UAPI validation to restrict userptr, svm and dmabuf mappings to be either 2WAY or XA+1WAY V5(Thomas): logic correction V4(MattA): Modify uapi doc and commit V3(MattA): check valid op and pat_index value V2(MattA): validate dma-buf bos and madvise pat-index Acked-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Michal Mrozek <michal.mrozek@intel.com> Acked-by: Carl Zhang <carl.zhang@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260305121902.1892593-9-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-03-23platform/x86: dell/dell-rbtn: Convert ACPI driver to a platform oneRafael J. Wysocki1-56/+52
In all cases in which a struct acpi_driver is used for binding a driver to an ACPI device object, a corresponding platform device is created by the ACPI core and that device is regarded as a proper representation of underlying hardware. Accordingly, a struct platform_driver should be used by driver code to bind to that device. There are multiple reasons why drivers should not bind directly to ACPI device objects [1]. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the Dell Airplane Mode Switch (rbtn) ACPI driver to a platform one. After this change, the subordinate rfkill device will be registered under the platform device used for driver binding instead of its ACPI companion. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/6141354.MhkbZ0Pkbq@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23platform/x86: dell/dell-rbtn: Register ACPI notify handler directlyRafael J. Wysocki1-17/+33
To facilitate subsequent conversion of the driver to a platform one, make it install an ACPI notify handler directly instead of using a .notify() callback in struct acpi_driver. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/9591832.CDJkKcVGEf@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-23drm/xe/pat: define coh_mode 2wayTejas Upadhyay4-11/+12
Defining 2way (two-way coherency) is critical for Xe3p_LPG (Nova Lake P) platforms to support L2 flush optimization safely. This mode allows the driver to skip certain manual cache flushes (L2 flush optimization) without risking memory corruption because the hardware ensures the most recent data is visible to both entities. Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260305121902.1892593-8-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-03-23drm/xe/xe3p_lpg: flush shrinker bo cachelines manuallyTejas Upadhyay3-1/+30
XA, new pat_index introduced post xe3p_lpg, is memory shared between the CPU and GPU is treated differently from other GPU memory when the Media engine is power-gated. XA is *always* flushed, like at the end-of-submssion (and maybe other places), just that internally as an optimisation hw doesn't need to make that a full flush (which will also include XA) when Media is off/powergated, since it doesn't need to worry about GT caches vs Media coherency, and only CPU vs GPU coherency, so can make that flush a targeted XA flush, since stuff tagged with XA now means it's shared with the CPU. The main implication is that we now need to somehow flush non-XA before freeing system memory pages, otherwise dirty cachelines could be flushed after the free (like if Media suddenly turns on and does a full flush) V4: Add comments for L2 flush path V3(Thomas/MattA/MattR): Restrict userptr with non-xa, then no need to flush manually V2(MattA): Expand commit description Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260305121902.1892593-7-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-03-23drm/xe/vf: Improve getting clean NULL contextMichal Wajdeczko4-4/+46
There is a small risk that when fetching a NULL context image the VF may get a tweaked context image prepared by another VF that was previously running on the engine before the GuC scheduler switched the VFs. To avoid that risk, without forcing GuC scheduler to trigger costly engine reset on every VF switch, use a watchdog mechanism that when configured with impossible condition, triggers an interrupt, which GuC will handle by doing an engine reset. Also adjust job size to account for additional dwords with watchdog setup. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260303201354.17948-4-michal.wajdeczko@intel.com
2026-03-23drm/xe: Add MI_SEMAPHORE_WAIT command definitionMichal Wajdeczko1-0/+13
This command supports memory based Semaphore WAIT. Memory based semaphores will be used for synchronization between the Producer and the Consumer contexts. Producer and Consumer Contexts could be running on different engines or on the same engine inside GT. Bspec: 45749, 60244 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260303201354.17948-3-michal.wajdeczko@intel.com
2026-03-23drm/xe: Add PR_CTR_CTRL/THRSH register definitionsMichal Wajdeczko1-0/+8
The Watchdog Counter Control and Watchdog Counter Threshold registers are needed for watchdog programming. This watchdog will generate the "Media Hang Notify" interrupt. Bspec: 45999, 46000 Bspec: 60373, 60374 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260303201354.17948-2-michal.wajdeczko@intel.com
2026-03-23platform/x86: system76: Convert ACPI driver to a platform oneRafael J. Wysocki1-23/+25
In all cases in which a struct acpi_driver is used for binding a driver to an ACPI device object, a corresponding platform device is created by the ACPI core and that device is regarded as a proper representation of underlying hardware. Accordingly, a struct platform_driver should be used by driver code to bind to that device. There are multiple reasons why drivers should not bind directly to ACPI device objects [1]. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the System76 ACPI driver to a platform one. After this change, the subordinate hwmon, input and LED class devices will be registered under the platform device used for driver binding instead of its ACPI companion. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3401648.aeNJFYEL58@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-03 09:39:59 +0300