summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-07-09drm/i915/doc: Document DP link capabilitiesImre Deak
Add documentation for the DP link capabilities interface. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-2-imre.deak@intel.com
2026-07-09mmc: core: add NXP IW61x base ID and block size quirkJeff Chen
The NXP IW61x series SDIO chipset identifies itself with a base card ID (0x0204) during the initial MMC bus scan, while the specific WLAN function reports a different ID (0x0205). To ensure that the MMC_QUIRK_BLKSZ_FOR_BYTE_MODE quirk is correctly inherited by all SDIO functions (including Wi-Fi), it must be attached to the base card ID at the core level. Add the SDIO_DEVICE_ID_NXP_IW61X_BASE definition and apply the required fixup in the SDIO quirk table. Signed-off-by: Jeff Chen <jeff.chen_1@nxp.com>
2026-07-09bus: mhi: ep: Fix device refcount leak in the error path of MHI device creationYuho Choi
mhi_ep_create_device() takes one device reference for the UL channel and another for the DL channel after allocating the transfer device. These references are normally released by mhi_ep_destroy_device() before the device itself is removed. If dev_set_name() or device_add() fails, the error path currently drops only one reference. The remaining channel references keep the device from being released and leave the channels associated with a device that was never registered. Route both failures through a common unwind path that drops the DL channel reference, the UL channel reference, and the initial reference from device_initialize(). Fixes: 297c77a0f273 ("bus: mhi: ep: Add support for creating and destroying MHI EP devices") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260603195142.2189386-1-dbgh9129@gmail.com
2026-07-09bus: mhi: core: Fix sys error transition latencyQingtao Cao
Bring forward the idea to fix the power down latency in mhi_pm_disable_transition() further to mhi_pm_sys_error_transition() so that the transition into system error (triggered by AT!RESET) in the modems won't have to return only after the timeout of up to 24 seconds. Once the device gets reset, there is no guarantee that it will send an interrupt to indicate the state transition. So polling is the sensible option here. Signed-off-by: Qingtao Cao <qingtao.cao.au@gmail.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Link: https://patch.msgid.link/20260603011333.3306102-2-qingtao.cao.au@gmail.com
2026-07-09Merge tag 'iio-fixes-for-7.2a' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-linus Jonathan writes: IIO: 1st set of fixes for the 7.2 cycle Usual mixed bag of recently introduced issues and much older ones. core - Ensure kfifo is reset before fd is allocated avoiding concurrent use of fifo with reset. multiple drivers - Fix up missing Kconfig dependencies. hid-sensors - Add support for multibyte read as necessary precursor to... - Fix stale or zero output when reading raw values for quaternions. adi,adis - Add IRQF_NO_THREAD to ensure interrupt is not pushed to the software interrupt chip used for trigger demux in the IIO core from a thread. bosch,bmc150 - Hardening against device returning a reserved out of range value for how many entries are in the FIFO. bosch,bmi160 - Add IRQF_NO_THREAD to ensure interrupt is not pushed to the software interrupt chip used for trigger demux in the IIO core from a thread. dynaimage,al3010 - Fix wrong scale for highest gain_range due to too many digits in the micro part (val2). freescale,mpl3115 - Fix unbalanced runtime pm on error in read_raw(). invensens,icm42600 - Avoid wrong divisor for fifo timestamps when using the watermark interrupt. - Fix timestamp accuracy loss due to excessive divisor for calculations. kionix,kxsd9 - Fix unbalanced runtime pm on an error in write_raw(). microchip,mcp37feb02 - Fix an uninitialized reference voltage value for particular DT config. melix,mlx90635 - Build on basis of right Kconfig symbol. nxp,lpc32xx - Ensure completion initialized before requesting irq. Hardening against spurious IRQ. nxp,saradc - Fix a delay calculation. sharp,gp2ap0002 - Fix unbalanced runtime pm on error in read_raw(). st,lsm6dsx - Fix an issue seen in wild where an unplanned CPU reset can leave the device on the wrong register page, thus leaving the driver wedged. st,st_sensors library - Make sure to handle a device that provides data as big endian correctly. st,spear - Ensure completion initialized before requesting irq. Hardening against spurious IRQ. taos,tsl2591 - Don't eat return from devm_request_threaded_irq() as that breaks deferred probing. ti,ads1119 - Fix a pm reference count leak in an error path. ti,ads124s08 - Handle gpio look up errors correctly. * tag 'iio-fixes-for-7.2a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (28 commits) iio: event: Fix event FIFO reset race iio: imu: inv_icm42600: fix timestamp clock period by using lower value iio: light: al3010: fix incorrect scale for the highest gain range iio: adc: nxp-sar-adc: Fix the delay calculation in nxp_sar_adc_wait_for() iio: light: tsl2591: return actual error from probe IRQ failure iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading iio: imu: st_lsm6dsx: deselect shub page before reading whoami iio: adc: ad7779: add missing 'select IIO_TRIGGERED_BUFFER' to Kconfig iio: adc: ad4130: add missing `select IIO_TRIGGERED_BUFFER` to Kconfig iio: adc: ti-ads124s08: Return reset GPIO lookup errors iio: temperature: Build mlx90635 with CONFIG_MLX90635 iio: light: al3320a: add missing REGMAP_I2C to Kconfig iio: light: al3010: add missing REGMAP_I2C to Kconfig iio: light: al3000a: add missing REGMAP_I2C to Kconfig iio: common: st_sensors: honour channel endianness in read_axis_data iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ iio: hid-sensor-rotation: Fix stale or zero output when reading raw values HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads iio: adc: spear: Initialize completion before requesting IRQ ...
2026-07-09efi/runtime-wrappers: retire the worker if a wedged call ever returnsBreno Leitao
When __efi_queue_work() times out it disables runtime services and returns, but the kworker is still blocked inside firmware. If the firmware eventually unblocks, efi_call_rts() would run its tail on an efi_rts_work that the timed-out caller has long abandoned: signalling a stale completion and clearing efi_runtime_lock_owner that may by then belong to another caller. If runtime services have been disabled by the time the call returns, park the worker with efi_rts_park_worker() instead, so it never touches efi_rts_work again or returns to the workqueue. Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-07-09efi/runtime-wrappers: honour EFI_RUNTIME_SERVICES in the non-blocking pathsBreno Leitao
Three wrappers call firmware directly instead of going through __efi_queue_work(), and none of them check whether runtime services are still enabled: virt_efi_set_variable_nb(), virt_efi_query_variable_info_nb() and virt_efi_reset_system(). Once a hang has cleared EFI_RUNTIME_SERVICES - or efi_recover_from_page_fault() has cleared it on a firmware page fault - these paths still enter the (possibly wedged) firmware, e.g. an EFI pstore write through the non-blocking SetVariable() variant, in violation of UEFI's non-reentrancy rules. reset_system() is reachable too: efi_reboot() only gates it on the static efi_rt_services_supported() mask, which does not track the runtime disable. Check efi_enabled(EFI_RUNTIME_SERVICES) in each before calling into firmware. Test it after taking efi_runtime_lock rather than before: the bit is only ever cleared at runtime while that lock is held, so checking it under the lock avoids racing with a concurrent timeout that clears the bit and drops the lock. Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-07-09efi/runtime-wrappers: bound the wait for EFI runtime service callsBreno Leitao
When an EFI runtime service hangs in firmware, the efi_rts_wq worker is stuck inside the call and cannot be cancelled. __efi_queue_work() then waits on the completion forever while holding efi_runtime_lock, so every later EFI caller is wedged until reboot; the only symptom is a "workqueue lockup" and tasks piling up on the semaphore. Replace wait_for_completion() with wait_for_completion_timeout() bounded by EFI_RTS_TIMEOUT (120 seconds). On timeout, clear EFI_RUNTIME_SERVICES and return EFI_ABORTED so later callers fail fast at the entry check instead of each paying another 120 seconds. The wedged worker is intentionally leaked and keeps ownership of efi_rts_work. A worker that only starts running after the timeout would otherwise dereference efi_rts_work.args, now pointing into the caller's freed stack frame, and hand stale pointers to firmware. Park it with efi_rts_park_worker() at the entry of efi_call_rts() when runtime services are already disabled, before it touches args or enters firmware. Known limitation: a worker already inside firmware when the timeout fires still holds efi_rts_args pointing into the caller's stack frame; if firmware unblocks afterwards and writes the output buffers, they land in reused memory. Firmware hung this long rarely recovers; a follow-up could bounce the buffers through kmalloc. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-07-09efi/runtime-wrappers: check EFI_RUNTIME_SERVICES before using efi_rts_workBreno Leitao
Move the EFI_RUNTIME_SERVICES check to the top of __efi_queue_work() and return directly, so a caller that finds runtime services disabled returns without touching the shared efi_rts_work. No functional change. This prepares for bounding the wait, where a timeout will clear EFI_RUNTIME_SERVICES while the leaked worker still owns efi_rts_work; a later caller must then bail out before reinitialising it. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-07-09efi/runtime-wrappers: handle queue_work() failure with goto exitBreno Leitao
Convert the queue_work() failure path in __efi_queue_work() to a goto exit instead of falling through to the wait and the WARN_ON_ONCE(status == EFI_ABORTED) below it. A failed queue_work() leaves the status at its initial EFI_ABORTED, so that warning would fire even though no call ran; it is meant for a completed call that returned EFI_ABORTED. No change for the common (successful enqueue) path. This also prepares __efi_queue_work() for the timeout handling added later. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-07-09efi/runtime-wrappers: factor out efi_rts_park_worker()Breno Leitao
x86's efi_crash_gracefully_on_page_fault() ends in an infinite schedule() loop so the kworker that faulted in firmware never runs efi_rts_wq again. A later change needs the same "park this worker forever" primitive on the runtime service timeout path, so factor the loop into a shared efi_rts_park_worker() and call it from the x86 page-fault handler. No functional change. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-07-09drm/i915/audio: treat UHBR SST like MST for cpu_transcoder signallingKai Vehmanen
Both DP MST and UHBR SST require the audio component to use a real cpu_transcoder (>= 0) value to identify the audio stream on a port. For DP MST this was already handled; for UHBR SST it was not, causing pin_eld_notify() to signal cpu_transcoder = -1 (the legacy SST sentinel) and find_audio_state() to skip the per-transcoder entry for the UHBR stream. After suspend/resume or replug, the ELD lookup fails and audio goes silent. Fix by detecting UHBR SST alongside DP MST when deciding whether a real cpu_transcoder value must be used for audio state addressing, in both the pin_eld_notify() signalling and the find_audio_state() lookup paths. --v2: - Commit message and comment update. (Suraj) - Change function name has_mst_transcoder. (Suraj) - Avoid Live crtc access in find_audio_state. (Suraj) --v3: - Minor comment changes to avoid MST over 128b/132b confusion. (Suraj) Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260708113558.1863316-1-mitulkumar.ajitkumar.golani@intel.com
2026-07-08scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()Abdun Nihaal
The memory allocated for mboxq using mempool_alloc() is not freed in some of the early exit error paths. Fix that by moving the mempool_free() call to an earlier point after last use. Fixes: d79c9e9d4b3d ("scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Reviewed-by: Justin Tee <justin.tee@broadcom.com> Link: https://patch.msgid.link/20260707065304.949135-1-nihaal@cse.iitm.ac.in Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-07-08scsi: sg: Report request-table problems when any status is setXu Rao
SG_GET_REQUEST_TABLE reports per-request diagnostic state through sg_req_info::problem. The field is meant to indicate whether there is an error to report for a completed request. sg_fill_request_table() currently combines masked_status, host_status and driver_status with bitwise AND. This only reports a problem when all three status fields are non-zero at the same time. A normal target check condition, for example, has masked_status set while host_status and driver_status may both be zero, so the request is incorrectly reported as clean. Use the same condition as sg_new_read(), which sets SG_INFO_CHECK when any of the three status fields is non-zero. Cc: stable@vger.kernel.org Signed-off-by: Xu Rao <raoxu@uniontech.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/54B60C19F7DB8889+20260707030845.970018-1-raoxu@uniontech.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-07-08scsi: ufs: core: tracing: Do not dereference pointers in TP_printk()Steven Rostedt
The trace events in drivers/ufs/core/ufs_trace.h were converted to take a pointer to the hba structure as an argument for the tracepoint and then in TP_printk() the printing of the dev_name from the ring buffer was converted to using the dev dereferenced pointer from the hba saved pointer. This is not allowed as the TP_printk() is executed at the time the trace event is read from /sys/kernel/tracing/trace file. That can happen literally, seconds, minutes, hours, weeks, days, or even months later! There is no guarantee that the hba pointer will still exist by the time it is dereferenced when the "trace" file is read. Instead, save the device name from the hba pointer at the time the tracepoint is called and place it into the ring buffer event. Then the TP_printk() can read the name directly from the ring buffer and remove the possibility that it will read a freed pointer and crash the kernel. This was detected when testing the trace event code that looks for TP_printk() parameters doing illegal derferences[1] [1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/ Cc: stable@vger.kernel.org Fixes: 583e518e7100 ("scsi: ufs: core: Add hba parameter to trace events") Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Reviewed-by: Peter Wang <peter.wang@mediatek.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260630185412.283c26c5@gandalf.local.home Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-07-08scsi: virtio_scsi: Fix up endian conversions for warning messagesBen Dooks
There are several places where printing functions are being passed parameters that have not been through endian conversion functions. Use virtio32_to_cpu() to fix the warnings. Fixes the following warnings from (prototype) sparse: drivers/scsi/virtio_scsi.c:126:9: warning: incorrect type in argument 7 (different base types) drivers/scsi/virtio_scsi.c:126:9: expected unsigned int drivers/scsi/virtio_scsi.c:126:9: got restricted __virtio32 [usertype] sense_len drivers/scsi/virtio_scsi.c:312:17: warning: incorrect type in argument 2 (different base types) drivers/scsi/virtio_scsi.c:312:17: expected unsigned int drivers/scsi/virtio_scsi.c:312:17: got restricted __virtio32 [usertype] reason drivers/scsi/virtio_scsi.c:412:17: warning: incorrect type in argument 2 (different base types) drivers/scsi/virtio_scsi.c:412:17: expected unsigned int drivers/scsi/virtio_scsi.c:412:17: got restricted __virtio32 [usertype] event Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Link: https://patch.msgid.link/20260623132427.838900-1-ben.dooks@codethink.co.uk Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-07-08Merge branch 7.2/scsi-queue into 7.2/scsi-fixesMartin K. Petersen
Pull in outstanding commits from 7.2/scsi-queue. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-07-09regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCKTimur Tabi
Compare against -EDEADLK, which is what ww_mutex_lock() actually returns and what every other deadlock check in this file already uses. Function regulator_lock_two() acquires two regulators via regulator_lock_nested() -> ww_mutex_lock(). On contention, ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop the lock it holds and retry the acquisition in the canonical order. However, regulator_lock_two() tests the return value against -EDEADLOCK rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are the same value, so the comparison happens to be correct and the bug is invisible. But on MIPS, SPARC, and PowerPC, those two errors have different values. The test is wrong: a genuine -EDEADLK backoff no longer matches -EDEADLOCK, so instead of unlocking and retrying, the code falls into WARN_ON(ret) and returns with only one of the two regulators locked. In practice, this is a bug only on MIPS, because the regulator core is not built or used on the other two platforms. In general, EDEADLK is preferred over EDEADLOCK for new code. Fixes: cba6cfdc7c3f ("regulator: core: Avoid lockdep reports when resolving supplies") Signed-off-by: Timur Tabi <ttabi@nvidia.com> Link: https://patch.msgid.link/20260708235722.2953579-1-ttabi@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-08drm/xe/guc: fix activity stats error message formatSk Anirban
Use ERR_PTR() to print the error code symbolically. This makes the failure easier to spot from IGT, e.g. when the device is wedged. Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260624194618.2793571-6-sk.anirban@intel.com
2026-07-08drm/xe/guc: distinguish wedged from recoverable cancellationSk Anirban
The CT layer returns -ECANCELED regardless of whether cancellation is due to a GT reset or a wedged device. Return -ENOTRECOVERABLE on wedge so callers don't need xe_device_wedged() checks to suppress spurious error logs. Also document the return codes of xe_guc_ct_send() in kernel-doc form. v2: Fix -ECANCELED description (Matt) Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260624194618.2793571-5-sk.anirban@intel.com
2026-07-08drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=nShuicheng Lin
When CONFIG_DRM_GPUSVM=n (e.g. um-allyesconfig), the only caller of xe_pt_svm_userptr_notifier_lock() is compiled out, triggering: drivers/gpu/drm/xe/xe_pt.c:1418:13: warning: 'xe_pt_svm_userptr_notifier_lock' defined but not used [-Wunused-function] The helpers cannot simply be removed in this case: the matching xe_pt_svm_userptr_notifier_unlock() is also referenced from xe_pt_update_ops_run(), which lives outside any DRM_GPUSVM ifdef and is gated only at runtime by pt_update_ops->needs_svm_lock. The symbol must exist in all builds. Provide empty static inline stubs for !DRM_GPUSVM, matching the pattern used by xe_svm_notifier_lock()/_unlock() in xe_svm.h. Fixes: 80ccbd97ffee ("drm/xe/userptr: Hold notifier_lock for write on inject test path") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606302210.QqcLbOEN-lkp@intel.com/ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630192221.2998168-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-07-08drm/amdkfd: Check bounds on CRIU restore queue type and mqd sizeDavid Francis
We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. Reviewed-by: David Yat Sin <david.yatsin@amd.com> Signed-off-by: David Francis <David.Francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5) Cc: stable@vger.kernel.org
2026-07-08drm/amd/pm: fix smu14 power limit range calculationYang Wang
SMU14 derives the default PPT limit from SocketPowerLimitAc/Dc, but MsgLimits.Power may expose a different firmware limit for the same PPT0 throttler. Using those values independently as fixed min/max bases can report an incorrect configurable power range. Keep the socket power limit as the default value and as the fallback for current-limit queries. Calculate the reported range from both firmware values instead, using the lower value as the minimum base and the higher value as the maximum base before applying OD percentages. Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c936b8126b444401318fcbeb1828488cc5312dee) Cc: stable@vger.kernel.org
2026-07-08drm/amdkfd: Check bounds in allocate_event_notification_slotDavid Francis
The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: David Yat Sin <david.yatsin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50) Cc: stable@vger.kernel.org
2026-07-08amdkfd: properly free secondary context idZhu Lingshan
Function kfd_process_free_id() should skip over the primary kfd process because its context id is fixed assigned, not allocated through the ida table. This function should only work on secondary contexts. Fixes: fac682a1d1af ("amdkfd: identify a secondary kfd process by its id") Signed-off-by: Zhu Lingshan <lingshan.zhu@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8799ba6fb6a48438aea20c82e74c2f2a3d2b2e7a) Cc: stable@vger.kernel.org
2026-07-08drm/amdkfd: Don't acquire buffers during CRIU queue restore.David Francis
kfd_criu_restore_queue's call of kfd_queue_acquire_buffers was failing for multiple reasons - The ctl_stack_size set by the CRIU plugin doesn't match what is expected by acquire_buffers - The svm buffer cannot be acquired at this point because CRIU may not have restored it, or may have restored it to a different address. The only reason acquire_buffers was necessary here was to avoid a null ptr dereference in init_user_queue. Just put in a check for that dereference; it doesn't appear to come up in real use cases right now. That is, there is no usage of CRIU with shared MES. This is a partial revert of commit 20a5e7ffdfec ("drm/amdkfd: Properly acquire queue buffers in CRIU restore") Fixes: 20a5e7ffdfec ("drm/amdkfd: Properly acquire queue buffers in CRIU restore") Reviewed-by: David Yat Sin <david.yatsin@amd.com> Signed-off-by: David Francis <David.Francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1cafa8b29e029eac3ddf64604f891b35dbf6262b) Cc: stable@vger.kernel.org
2026-07-08drm/amdkfd: Check bounds on CRIU restore event idDavid Francis
The valid amdkfd event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT - 1. During CRIU restore, ensure that the provided event ids are in that range. v2: No need for lower bound check since idr_alloc rejects negative inputs v3: Also change error message to reflect new error condition Reviewed-by: David Yat Sin <david.yatsin@amd.com> Signed-off-by: David Francis <David.Francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 5c6c247992d4d9200e073b83f4ec6c703c096845)
2026-07-08drm/gfx10: Program DB_RING_CONTROLAlex Deucher
This is needed to allocate occlusion counters across both gfx pipes. Fixes: b7a1a0ef12b8 ("drm/amd/amdgpu: add pipe1 hardware support") Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6807352cbabb74b61ba42888769283af72191f66) Cc: stable@vger.kernel.org
2026-07-08dm era: fix error code propagation in era_ctr()Cao Guanghui
era_ctr() replaces the actual error codes returned by dm_get_device() and dm_set_target_max_io_len() with hardcoded -EINVAL, discarding the real reason for the failure (e.g. -ENODEV, -ENOMEM). This makes it harder for users to diagnose problems and is inconsistent with other dm targets (dm-thin, dm-verity, dm-flakey, dm-ebs) which propagate the original error. Fix all three sites to return 'r' instead of -EINVAL. Signed-off-by: Cao Guanghui <caoguanghui@kylinos.cn> Reviewed-by: Su Yue <glass.su@suse.com> Reviewed-by: Ming-Hung Tsai <mtsai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-08dm era: fix NULL pointer dereference in metadata_open()Cao Guanghui
metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed. Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern. Fixes: eec40579d848 ("dm: add era target") Signed-off-by: Cao Guanghui <caoguanghui@kylinos.cn> Reviewed-by: Su Yue <glass.su@suse.com> Reviewed-by: Ming-Hung Tsai <mtsai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-08dm: avoid leaking the caller's thread keyring via the table device fileIngo Blechschmidt
The refactoring in commit a28d893eb327 ("md: port block device access to file") accidentally causes the caller's thread keyring to be kept alive long beyond the caller's lifetime. As a result, "cryptsetup luksSuspend" silently fails to wipe the LUKS volume key from memory. In detail: "cryptsetup luksOpen" uses its supposedly ephemeral thread keyring to pass the volume key to the kernel. dm-crypt's crypt_set_keyring_key() copies the key material into its own crypt_config structure and then drops its own reference to the key in the keyring with key_put(). With this fix, restoring pre-v6.9 behavior, the copy in the thread keyring is then promptly garbage collected, such that exactly one copy of the volume key remains. This single copy is correctly wiped from memory on "cryptsetup luksSuspend". Without this fix, the thread keyring and the volume key in it remains. This second copy is only freed on "luksClose". "luksSuspend" neither knows about this copy nor has any way to remove it, so the key remains recoverable from RAM after a suspend that is documented to have wiped it. This fix should not introduce new security problems, as the code is anyway gated by CAP_SYS_ADMIN. The device-mapper core, not the calling task, is the legitimate owner of this long-lived file. Fixes: a28d893eb327 ("md: port block device access to file") Closes: https://gitlab.com/cryptsetup/cryptsetup/-/work_items/993 Link: https://www.speicherleck.de/iblech/cryptsetup-luksSuspend-issue-reproduction/ Signed-off-by: Ingo Blechschmidt <iblech@speicherleck.de> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Tested-by: Ondrej Kozina <okozina@redhat.com>
2026-07-08dm-inlinecrypt: Fix an error handling path in inlinecrypt_ctr()Christophe JAILLET
All error handling paths, except but this one, branch to the 'bad' label in the error handling path. If not done, there is a memory leak and some sensitive data may be kept around. So, fix this error path and also do the needed clean-up. Also, fix missing goto in the "Wrong alignment of iv_offset sector" path. Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-08dm-pcache: reject option groups without valuesSamuel Moelius
The pcache target parses optional arguments as name/value pairs. A table that advertises one optional argument and supplies only a recognized option name, for example "cache_mode", reaches parse_cache_opts() with argc == 1. The parser consumes the name, decrements argc to zero, then calls dm_shift_arg() again for the value. dm_shift_arg() returns NULL when no arguments remain, and the following strcmp() dereferences that NULL pointer. Check that each recognized option has a value before consuming it. This keeps valid "cache_mode writeback" and "data_crc true/false" tables unchanged while making malformed tables fail during target construction with a precise missing-value error. Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> Reviewed-by: Zheng Gu <cengku@gmail.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org
2026-07-08dm thin metadata: fix metadata snapshot consistency on commit failureMing-Hung Tsai
__reserve_metadata_snap() and __release_metadata_snap() modify the superblock's held_root directly in the block_manager's buffer. If the subsequent metadata commit fails, the held_root gets flushed to disk through the abort_transaction path, resulting in inconsistent metadata. Reproducer 1: __reserve_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 14th block inaccessible, to trigger metadata commit failure in the subsequent reserve_metadata_snap operation. The 14th block will be the shadow destination for the index block. dmsetup create tmeta --table "0 112 linear /dev/sdc 0 112 3984 error" 2. Create a 16 MiB thin-pool dmsetup create tdata --table "0 32768 zero" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \ /dev/mapper/tdata 128 0 1 skip_block_zeroing" 3. Take a metadata snapshot to trigger metadata commit failure and transaction abort. However, the held_root is written to disk, breaking metadata consistency. dmsetup message tpool 0 "reserve_metadata_snap" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 2, but space map contains 1. Bad reference count for metadata block 7. Expected 2, but space map contains 1. Bad reference count for metadata block 13. Expected 1, but space map contains 0. Reproducer 2: __release_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 16th block inaccessible, to trigger metadata commit failure in the subsequent release_metadata_snap operation. The 16th block will be the shadow destination for the index block. dmsetup create tmeta --table "0 128 linear /dev/sdc 0 128 3968 error" 2. Create a 16 MiB thin-pool dmsetup create tdata --table "0 32768 zero" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \ /dev/mapper/tdata 128 0 1 skip_block_zeroing" 3. Reserve then release the metadata snapshot, to trigger metadata commit failure and transaction abort. The held_root gets removed from the on-disk superblock, causing inconsistent metadata. dmsetup message tpool 0 "reserve_metadata_snap" dmsetup message tpool 0 "release_metadata_snap" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 1, but space map contains 2. Bad reference count for metadata block 7. Expected 1, but space map contains 2. 1 metadata blocks have leaked. Fix by deferring the held_root update to commit time. Additionally, move the existing-snapshot check in __reserve_metadata_snap before the shadow operation to avoid unnecessary work. In __release_metadata_snap, clear pmd->held_root before btree deletion so partial failure leaks blocks rather than leaving a stale reference, and unlock the snapshot block before decrementing its refcount. Fixes: 991d9fa02da0 ("dm: add thin provisioning target") Cc: stable@vger.kernel.org Signed-off-by: Ming-Hung Tsai <mtsai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-08dm-verity: fix buffer overflow in FEC calculationMikulas Patocka
There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) fio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Assisted-by: Claude:claude-opus-4-6 Cc: stable@vger.kernel.org Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-08dm era: fix out-of-bounds memory access for non-zero start sectorSamuel Moelius
dm-era tracks writes in target-relative blocks, but era_map() calculates the writeset block before applying the target offset. Tables with a non-zero start sector can therefore pass an absolute mapped-device block to metadata_current_marked(). If the absolute block is beyond the current writeset size, writeset_marked() tests past the end of the in-core bitset. KASAN reports this as a vmalloc-out-of-bounds access. Apply the target offset before calculating the era block so writeset lookups use the target-relative block number. Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> Reviewed-by: Ming-Hung Tsai <mtsai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Fixes: eec40579d848 ("dm: add era target")
2026-07-08dm-log: fix a bitset_size overflow on 32bit machinesBenjamin Marzinski
Commit c20e36b7631d ("dm log: fix out-of-bounds write due to region_count overflow") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid. Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits. Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: c20e36b7631d ("dm log: fix out-of-bounds write due to region_count overflow") Cc: stable@vger.kernel.org
2026-07-08drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()Shahyan Soltani
The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. Signed-off-by: Shahyan Soltani <shahyan.soltani@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7) Cc: stable@vger.kernel.org
2026-07-08drm/amdgpu: trigger GPU recovery when userq destroy fails to unmap a hung queueJesse Zhang
Destroying a hung user queue issues a MES REMOVE_QUEUE that times out, The destroy path only logged the error and freed the queue, so the next userq submission failed and forced a GPU reset attributed to an innocent workload. Kick the userq reset work when unmap fails so the GPU is recovered at destroy time. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8396b9de4198a54ec4760a94a179347540a9764d) Cc: stable@vger.kernel.org
2026-07-08drm/amd/amdgpu: disable ASPM on VI if pcie dpm is disabledKenneth Feng
Disable ASPM on VI if PCIE dpm is disabled. Fixes: bb00bf17328d ("drm/amd/amdgpu: decouple ASPM with pcie dpm") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5370 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 873a8d6b3c0a386408c891e4ff1c684fa11783e1) Cc: stable@vger.kernel.org
2026-07-08drm/amdgpu: Disable JDPG on VCN5_3Suresh Guttula
JDPG does not support on VCN5 This patch will disable JDPG, because DPG is not correctly copying the JRBC Read/Write Pointers (R/WPTR) from the PG (Power Gating) block to JRBC. Signed-off-by: Suresh Guttula <suresh.guttula@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ea3fdd1eda088030d8925f023613728969f55955)
2026-07-08drm/amdgpu: add support for SMU version 15.0.9Kanala Ramalingeswara Reddy
Initialize SMU Version 15_0_9 Signed-off-by: Kanala Ramalingeswara Reddy <Kanala.RamalingeswaraReddy@amd.com> Signed-off-by: Granthali Vinodkumar Dhandar <granthali.vinodkumardhandar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1dfd4e84b5beec353a81d61af9eaf4e5a56e0c57)
2026-07-08drm/amdgpu: add support for PSP version 15.0.9Kanala Ramalingeswara Reddy
Initialize PSP Version 15_0_9 Signed-off-by: Kanala Ramalingeswara Reddy <Kanala.RamalingeswaraReddy@amd.com> Signed-off-by: Granthali Vinodkumar Dhandar <granthali.vinodkumardhandar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ef71f00173228904763552b7405169023f8034a8)
2026-07-08drm/xe: free madvise VMA array on L2 flush failureGuangshuo Li
xe_vm_madvise_ioctl() allocates madvise_range.vmas in get_vmas(). After get_vmas() succeeds with at least one VMA, error paths must go through free_vmas so the array is released before the madvise details are destroyed. The L2 flush validation path added for PAT madvise rejects some SVM/userptr ranges after get_vmas() has succeeded, but jumps directly to madv_fini. This skips kfree(madvise_range.vmas), leaking the VMA array on each failed ioctl. Jump to free_vmas instead, matching the other validation failure paths after get_vmas() has succeeded. Fixes: 4f39a194d41e ("drm/xe/xe3p_lpg: Restrict UAPI to enable L2 flush optimization") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260708073422.725186-1-lgs201920130244@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-08media: i2c: imx678: Add driver for Sony IMX678Jai Luthra
Add a V4L2 subdev driver for the Sony IMX678 image sensor. IMX678 is a diagonal 8.86 mm (Type 1/1.8) CMOS active pixel type solid-state image sensor with a square pixel array and 8.40 M effective pixels. The following features are supported by this driver: - MIPI RAW12 output - Monochrome and Color (Bayer filter) variants - Multiple input clock frequencies - Multiple link frequencies - VBLANK and HBLANK control for variable framerate - VFLIP and HFLIP control for flipping readout - Exposure and analogue gain control - Test pattern control Following features are not currently supported: - MIPI RAW10 output - Pixel-perfect crop reporting, accounting for the shift-by-1 when doing HFLIP/VFLIP where the sensor maintains RGGB bayer ordering Along with the ones below which depend on the new raw sensor model: - Embedded data stream - Freely configurable cropping - Increased framerate when cropping - 2x2 binning support Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com> Reviewed-by: Tarang Raval <tarang.raval@siliconsignals.io> [Sakari Ailus: Add an extra newline to the enum_mbus_code op.] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-08regulator: mt6363: add missing MODULE_DEVICE_TABLE()Pengpeng Hou
The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260704124352.7981-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-08regulator: mt6316: add missing MODULE_DEVICE_TABLE()Pengpeng Hou
The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260704122926.21586-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-08drm/amdkfd: Check bounds on CRIU restore event idDavid Francis
The valid amdkfd event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT - 1. During CRIU restore, ensure that the provided event ids are in that range. v2: No need for lower bound check since idr_alloc rejects negative inputs v3: Also change error message to reflect new error condition Reviewed-by: David Yat Sin <david.yatsin@amd.com> Signed-off-by: David Francis <David.Francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-08drm/amdkfd: expose pasid of secondary contexts by debugfsZhu Lingshan
Current kfd debugfs interfaces only expose pasid of the primary process, this commit exposes pasid of secondary contexts by debugfs Just like entries under sysfs, the secondary contexts are named as context_<id> under its primary kfd process. The layout: /sys/kernel/debug/kfd/proc# tree . └── 5802 ├── context_0 │   ├── pasid_1025 │   └── pasid_63266 ├── context_1 │   ├── pasid_1025 │   └── pasid_63266 ├── pasid_1025 └── pasid_63266 Another fix is, kfd_debugfs_add_process may fail, this commit change it to return a meaningful value other than void Signed-off-by: Zhu Lingshan <lingshan.zhu@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-08drm/amd/pm: fix smu14 power limit range calculationYang Wang
SMU14 derives the default PPT limit from SocketPowerLimitAc/Dc, but MsgLimits.Power may expose a different firmware limit for the same PPT0 throttler. Using those values independently as fixed min/max bases can report an incorrect configurable power range. Keep the socket power limit as the default value and as the fallback for current-limit queries. Calculate the reported range from both firmware values instead, using the lower value as the minimum base and the higher value as the maximum base before applying OD percentages. Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-08 08:47:05 +0000