| Age | Commit message (Collapse) | Author |
|---|
|
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
Driver Changes:
- Wedge from the timeout handler only after releasing the queue (Rodrigo)
- Fix a NULL pointer dereference (Francois)
- Remove redundant exec_queue_suspended (Lu)
- RTP / OA whitelist fixes (Ashutosh, Gustavo, Thomas)
- Return error on non-migratable faults requiring devmem (Matt Brost)
- Skip FORCE_WC and vm_bound check for external dma-bufs (Matt Auld)
- Hold notifier lock for write on inject test path (Shuicheng)
- Drop bogus static from finish in force_invalidate (Shuicheng)
- Fix double-free of managed BO in error path (Shuicheng)
- Don't attempt to process FAST_REQ or EVENT relays (Michal)
- Fix NPD in bo_meminfo (Matthew Auld)
- Prevent invalid cursor access for purged BOs (Matthew Auld)
- Fix offset alignment for MERT WHITELST_OA_MERT_MMIO_TRG (Ashutosh)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
Link: https://patch.msgid.link/akZ_UbrL94G4F2iA@fedora
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-fixes-7.2-2026-07-02:
amdgpu:
- Soc24 aborted suspend fix
- Drop unecessary BUG() and BUG_ON() from error paths
- SCPM fix
- Power reporting fix
- DCE HDR fix
- UVD boundary checks
- VCN boundary checks
- VCE boundary checks
- DCN 4.2 fixes
- Large stack allocation fixes
- Fix aperture mapping leak
- UserQ fixes
- Ignore_damage_clips fix
- ACP fixes
- DC boundary checks
- GPUVM fixes
- JPEG idle check fixes
- Userptr fix
- GC 11.7 updates
- Non-4K page fix
- SMU 13 fixes
- DP alt mode fix
amdkfd:
- Boundary checks
- CRIU fixes
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260702143138.68463-1-alexander.deucher@amd.com
|
|
On multi-tile platforms, we need to probe the hardware for the number
of tiles that are present in the platform. That means that we should
do that as part of xe_probe_info() instead of xe_info_init(). Do
that.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-9-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The value of xe->info.tile_count is only really valid after
xe_info_probe_tile_count(). Any use of tile_count before that point
is invalid and, consequently, initializing it in xe_info_init_early()
is pointless.
Move the initialization to xe_info_probe_tile_count().
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-8-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
On GMDID-based platforms, the driver needs to probe the hardware by
reading GMDID registers in order to identify the
graphics/media/display IPs that are present in the platform as well as
their stepping values.
Currently, xe_info_init() has such a probing logic, but that task
should be rather responsibility of xe_probe_info(). As such, move it
to the latter.
For pre-GMDID platforms, the IPs are identified via PCI devid and
revid fields, which is arguably also hardware dependent. So do the
same for those platforms.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-7-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
Currently the logic to set the graphics step for non-GMDID-based
platforms in kunit testing is defined in xe_wa_test_init(). That
logic should rather belong to the helper xe_pci_fake_device_init(), so
move it there.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-6-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The platform-level step information depends on the PCI revid and, as
such, should be probed in xe_probe_info_early() instead of
xe_info_init_early(). Move the code accordingly.
Note that we currently only update probed_info->step.platform as part
of this change. We will deal with the other fields of
probed_info->step as a follow-up change, which will be tied to the
probing of graphics and media IPs.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-5-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
Currently xe_step_platform_get() uses info fields from xe->info to
define the platform-level stepping value.
Because the platform-level stepping info depends on the PCI revid, it
should be defined as part of xe_probe_info_early() instead of being
directly probed inside xe_info_init_early().
Let's make sure that xe_step_platform_get() receives the necessary
data as parameters and does not depend on xe->info. That will allow
us to move the call up to xe_probe_info_early() in an upcoming change.
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-4-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The PCI devid and revid fields are info that we probe from the
hardware (indirectly via the PCI subsystem). Add them to
xe_probed_info and set them via xe_probe_info_early(), since the
respective fields in xe->info are updated in xe_info_init_early().
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-3-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The xe_step_*_get() functions update the step directly in
xe->info.step and are called by functions xe_info_init_early() and
xe_info_init().
As the stepping info is something probed from the hardware (via PCI
revid and/or GMDID) and we want to move away from probing inside
xe_info_init*() functions, let's make xe_step_*_get() functions modify
a pointer to the step structure instead of modifying xe->info.step
directly: this will allow an upcoming change that will move those
function calls out of the info init functions and will pass a member
of struct xe_probed_info instead of xe->info.step.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-2-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
Functions xe_info_init_early() and xe_info_init() currently probe some
information from the hardware while doing initialization of info
fields. Besides mixing responsibilities, another issue from this
approach is that kunit tests need to implement static stubs for the
probing part.
Let's prepare the ground to ensuring that those functions stop probing
the information from the hardware by creating the necessary framework
for extracting the probing bits out of them. Do that by creating a
new struct type called xe_probed_info and the functions responsible
for populating it.
In upcoming changes, we will gradually refactor the code so that all
info needed by xe_info_init_early() and xe_info_init() that is probed
from the hardware is passed to them via struct xe_probed_info.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-1-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set
unconditionally even when ath11k_core_qmi_firmware_ready() fails.
This leaves the driver in an inconsistent state where
initialization is considered complete although the firmware ready
handling did not finish successfully. During the subsequent SSR,
the driver enters the restart path based on this incorrect state
and dereferences uninitialized srng members, resulting in a NULL
pointer dereference.
Call trace:
ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P)
ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k]
ath11k_core_restart+0x40/0x168 [ath11k]
Fix this by:
- skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set
- setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds
- setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling
on error
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1
Fixes: 6fe62a8cec51c ("wifi: ath11k: Add cold boot calibration support on WCN6750")
Signed-off-by: Gaole Zhang <gaole.zhang@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260609090609.4041009-1-gaole.zhang@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
The aggr_reset_state() function uses timer_delete() (non-synchronous)
for the aggregation timer before proceeding to delete TID state and
before the structure is freed by callers like aggr_module_destroy().
If the timer callback (aggr_timeout) is executing when aggr_reset_state()
is called, the callback will continue to access aggr_conn fields like
rx_tid[] and stat[] which may be freed immediately after by
kfree(aggr_info->aggr_conn) in aggr_module_destroy().
Additionally, the timer callback can re-arm itself via mod_timer() while
aggr_reset_state() is running, creating a more complex race condition.
Use timer_delete_sync() instead to ensure any running timer callback
has completed before returning.
Fixes: bdcd81707973 ("Add ath6kl cleaned up driver")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Hodges <git@danielhodges.dev>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260206185207.30098-1-git@danielhodges.dev
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
ath9k_hif_request_firmware() re-arms an asynchronous firmware load via
request_firmware_nowait(), passing hif_dev as the completion context, and
then still dereferences hif_dev:
dev_info(&hif_dev->udev->dev, "ath9k_htc: Firmware %s requested\n",
hif_dev->fw_name);
The re-armed callback ath9k_hif_usb_firmware_cb() runs on the "events"
workqueue and, when the firmware is missing, walks the retry chain into
ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That
releases the wait_for_completion(&hif_dev->fw_done) in a concurrent
ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing
dev_info() in the frame that re-armed the request can therefore read freed
memory (hif_dev->udev, the first field of struct hif_device_usb):
BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware
Read of size 8 ... by task kworker/...
ath9k_hif_request_firmware
ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247
request_firmware_work_func
Allocated by ...:
ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c
Freed by ...:
ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c
The fw_done barrier only makes disconnect wait for the firmware chain to
*terminate*; it does not protect the outer ath9k_hif_request_firmware()
frame that re-armed the request and keeps touching hif_dev afterwards.
Drop the post-request dev_info(): it is the only use of hif_dev after the
async request is armed, and it is purely informational (the dev_err() on the
failure path runs only when request_firmware_nowait() did not arm a callback,
so hif_dev is still alive there).
This was first reported by syzbot as a single, non-reproduced crash that was
later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer,
which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc
device whose firmware download fails). The vulnerable code is unchanged and
still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN
once the (sub-microsecond) race window is widened.
Fixes: e904cf6fe230 ("ath9k_htc: introduce support for different fw versions")
Reported-by: syzbot+50122cbc2874b1eb25b0@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=50122cbc2874b1eb25b0
Signed-off-by: Cheng Yongkang <teel4res@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260605153210.20471-1-1020691186@qq.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
inv_icm45600_buffer_fifo_read() uses the FIFO_COUNT the device reports,
unclamped, as the length of a regmap_noinc_read() into the fixed
INV_ICM45600_FIFO_SIZE_MAX (8 KiB) st->fifo.data buffer. The only bound is
the caller's "max", which the interrupt path skips (it passes 0). A device,
or an attacker on the bus, reporting up to 65535 makes the read as large as
~1 MiB: a heap out-of-bounds write of device-controlled data.
Clamp st->fifo.count to the buffer capacity before the read, and allocate
the buffer with the same INV_ICM45600_FIFO_SIZE_MAX define, so the bound
and the allocation reference one constant. The clamp is a no-op for
conforming hardware.
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
device exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
device exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
device exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
device exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
device exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Fixes: fc18dddc0625 ("iio: hid-sensors: Added device rotation support")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
ownership transferred to rdata
In max8998_pmic_dt_parse_pdata(), of_get_child_by_name() acquires a
reference on reg_np which is then stored in rdata->reg_node, transferring
ownership to the regulator data array. The subsequent of_node_put(reg_np)
at the end of the function releases the last matched regulator node's
reference, leaving rdata->reg_node as a dangling pointer for the last
entry.
Remove the spurious of_node_put(reg_np) call.
Cc: stable@vger.kernel.org
Fixes: 156f252857df ("drivers: regulator: add Maxim 8998 driver")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260626160326.54457-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
siw_create_qp() currently calls siw_qp_add() before the queues, CQ
pointers, state, completion, and device list entry are ready. A QPN
lookup can therefore reach a QP that is still being constructed.
Move siw_qp_add() to the end of siw_create_qp(), after QP
initialization and before adding the QP to the siw device list.
Fixes: f29dd55b0236 ("rdma/siw: queue pair methods")
Link: https://patch.msgid.link/r/20260630060040.966461-1-ruoyuw560@gmail.com
Suggested-by: Bernard Metzler <bernard.metzler@linux.dev>
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Acked-by: Bernard Metzler <bernard.metzler@linux.dev>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
Remove extra asterisk to avoid the following kernel-doc warning:
Warning: drivers/infiniband/hw/mlx5/umr.c:986 This comment starts with '/**',
but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst
Fixes: e73242aa14d2 ("RDMA/mlx5: Optimize DMABUF mkey page size")
Link: https://patch.msgid.link/r/20260629-kdoc-fix-v1-1-735a90dede7f@nvidia.com
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
Fix spelling errors in iwpm_msg.c, changing 'quite' to 'quiet'.
Link: https://patch.msgid.link/r/20260629023153.357709-1-l1138897701@163.com
Signed-off-by: luoqing <luoqing@kylinos.cn>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
When vm_insert_pages() fails, the error path calls vma->vm_ops->close(vma)
which internally calls drm_gem_vm_close() → drm_gem_object_put(),
releasing the GEM object reference acquired at the start of the function.
However, the close_vma label then falls through to put_obj, which calls
drm_gem_object_put() a second time on the same object.
If the first put releases the last reference, the object is freed and the
second put accesses freed memory, causing a use-after-free.
Fix by returning directly from close_vma instead of falling through to
put_obj, since the close handler already performs all necessary cleanup
including the object put.
Cc: stable@vger.kernel.org
Fixes: e486147c912f ("accel/amdxdna: Add BO import and export")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260625113239.49764-1-vulab@iscas.ac.cn
|
|
Add a blank line after variable declarations and remove multiple blank
line across HID sensor IIO drivers to improve readability and align
with kernel coding style.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
kmemdup() is used for memory that is logically tied to the HID
platform device, even though the driver binds into the IIO framework.
Using &indio_dev->dev for devres allocations works functionally, but it
results in two separate devres ownership trees—one for the HID
platform device (pdev) and another for the IIO device (indio_dev).
The devres framework is intended to have a single, well-defined parent
device. Since the memory originates from HID sensor probing and is not
IIO-specific, &pdev->dev is the correct and logical owner.
Switch to using the platform device for devm_kmemdup() so that all
resources are released deterministically and consistently.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
kmemdup() is used for memory that is logically tied to the HID
platform device, even though the driver binds into the IIO framework.
Using &indio_dev->dev for devres allocations works functionally, but it
results in two separate devres ownership trees—one for the HID
platform device (pdev) and another for the IIO device (indio_dev).
The devres framework is intended to have a single, well-defined parent
device. Since the memory originates from HID sensor probing and is not
IIO-specific, &pdev->dev is the correct and logical owner.
Switch to using the platform device for devm_kmemdup() so that all
resources are released deterministically and consistently.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
kmemdup() is used for memory that is logically tied to the HID
platform device, even though the driver binds into the IIO framework.
Using &indio_dev->dev for devres allocations works functionally, but it
results in two separate devres ownership trees—one for the HID
platform device (pdev) and another for the IIO device (indio_dev).
The devres framework is intended to have a single, well-defined parent
device. Since the memory originates from HID sensor probing and is not
IIO-specific, &pdev->dev is the correct and logical owner.
Switch to using the platform device for devm_kmemdup() so that all
resources are released deterministically and consistently.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Tested-by: Zhang Lixu <lixu.zhang@intel.com>
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
In hns_roce_cleanup_mhop_hem_table(), the expression:
obj = i * buf_chunk_size / table->obj_size;
is evaluated using 32-bit unsigned arithmetic because
'buf_chunk_size' is u32 and the usual arithmetic conversions convert
'i' to unsigned int. The result is assigned to a u64 variable, but the
multiplication may overflow before the assignment.
For sufficiently large HEM tables, this produces an incorrect object
index passed to hns_roce_table_mhop_put().
Cast 'i' to u64 before the multiplication so that the intermediate
calculation is performed with 64-bit arithmetic.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: a25d13cbe816 ("RDMA/hns: Add the interfaces to support multi hop addressing for the contexts in hip08")
Link: https://patch.msgid.link/r/20260627095951.51378-1-listdansp@mail.ru
Signed-off-by: Danila Chernetsov <listdansp@mail.ru>
Reviewed-by: Junxian Huang <huangjunxian6@hisilicon.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
Move the zero CQE validation before rdma_zalloc_drv_obj() to avoid
leaking the CQ object when returning -EINVAL.
Fixes: a2917582887a ("RDMA/core: Reject zero CQE count")
Link: https://patch.msgid.link/r/20260625020148.224537-1-zhaochenguang@kylinos.cn
Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
mana_ib_post_send() returns err after walking the send work request list.
If the caller passes an empty list, the loop is skipped and err is not
assigned.
Initialize err to 0 so an empty send work request list returns success
instead of stack data.
Fixes: c8017f5b4856 ("RDMA/mana_ib: UD/GSI work requests")
Link: https://patch.msgid.link/r/20260618041752.481193-2-ruoyuw560@gmail.com
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
erdma_post_recv() returns ret after walking the receive work request list.
If the caller passes an empty list, the loop is skipped and ret is not
assigned.
Initialize ret to 0 so an empty receive work request list returns success
instead of stack data.
Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation")
Link: https://patch.msgid.link/r/20260618041752.481193-1-ruoyuw560@gmail.com
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Reviewed-by: Cheng Xu <chengyou@linux.alibaba.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
Fix several comment misspellings across drivers/iio/imu/, found with
codespell and manual review. The corrected words are coefficient,
temperature, sensitivity, access, chosen, and buses.
Signed-off-by: Anas Khan <anxkhn28@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
The Kconfig entry for the AD7779 is missing a
'select IIO_TRIGGERED_BUFFER' parameter, causing build failures.
Fixes: c9a3f8c7bfcb ("drivers: iio: adc: add support for ad777x family")
Cc: stable@vger.kernel.org
Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
Tested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
The Kconfig entry is missing a `select IIO_TRIGGERED_BUFFER` parameter,
causing potential build failures.
Fixes: ec98c3b50157 ("iio: adc: ad4130: add new supported parts")
Cc: stable@vger.kernel.org
Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Previously, the user QP creation path would only attempt to
populate iwqp->iwpbl if the user-provided req.user_wqe_bufs
field was non-zero. The problem is that iwqp->iwpbl is
unconditionally dereferenced later on in irdma_setup_virt_qp.
While there was a check for iwqp->iwpbl != NULL, this check
would only occur if req.user_wqe_bufs was non-zero. The end
result is that a user could send a zero user_wqe_bufs value
and trigger a null ptr deref.
Fix this by unconditionally calling irdma_get_pbl and bailing
if it fails, similar to the CQ and SRQ paths.
Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
Link: https://patch.msgid.link/r/20260617164013.280790-1-jmoroni@google.com
Signed-off-by: Jacob Moroni <jmoroni@google.com>
Reviewed-by: David Hu <xuehaohu@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
devm_request_irq() already prints an error message on failure via the
IRQ core, so wrapping its return value in dev_err_probe() results in a
duplicate error message. Return the error directly instead.
Suggested-by: Joshua Crofts <joshua.crofts1@gmail.com>
Signed-off-by: Moksh Panicker <mokshpanicker.7@gmail.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
xe_vm_populate_pgtable() indexed the source PTE array (update->pt_entries)
by the per-call loop counter, assuming each call starts at the first entry
of the update. That holds for the CPU bind path
(xe_migrate_update_pgtables_cpu), which populates a whole update in a single
call, but not for the GPU bind path: write_pgtable() splits an update into
MAX_PTE_PER_SDI (510) sized MI_STORE_DATA_IMM chunks, invoking the populate
callback once per chunk with an advancing qword_ofs but a fresh command-
buffer destination pointer.
As a result, every chunk after the first re-read pt_entries from index 0
instead of from its true offset, so PTEs beyond the first 510 entries of a
single update were programmed with the wrong physical pages, shifting the
mapping by exactly MAX_PTE_PER_SDI pages.
This stayed latent because a single update only exceeds 510 qwords when a
large (e.g. 2M) region is bound as individual 4K PTEs rather than a single
huge-page entry, which happens when the backing store is sufficiently
fragmented. It was surfaced by the BO defrag path, which deliberately
rebinds such fragmented ranges via the GPU bind path, producing
deterministic data corruption offset by 510 pages.
Index pt_entries by the chunk's absolute offset relative to update->ofs so
both the CPU and GPU paths pick the correct entries.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Cc: stable@vger.kernel.org
Assisted-by: GitHub_Copilot:claude-opus-4.8
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260702012434.3861171-1-matthew.brost@intel.com
|
|
struct ad7779_state contains a completion field that is initialized
in ad7779_setup_without_backend() but never waited on or signaled
anywhere in the driver. Remove the dead code.
Suggested-by: Joshua Crofts <joshua.crofts1@gmail.com>
Signed-off-by: Moksh Panicker <mokshpanicker.7@gmail.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Fix several comment typos in industrialio-backend.c: correct "through"
in a channel-spec comment, "initiates a process" in the activation
comment, and drop a stray apostrophe from "Gets" in two getter
kerneldoc comments.
Signed-off-by: Anas Khan <anxkhn28@gmail.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
The original commit missed that three drivers (mthca, irdma, siw) have UHW
data associated with reg_mr that cannot be passed through the ioctl. They
also assume that the udata cannot be NULL, so failing to pass a valid
udata can trigger a NULL udata crash in those drivers.
This never happens in real systems since in rdma-core ibv_cmd_reg_mr_ex()
does not accept a udata and those three drivers don't use it, however a
malicious userspace could trigger it.
Cc: stable@vger.kernel.org
Fixes: 5b2e45049dc0 ("IB/core: Add UVERBS_METHOD_REG_MR on the MR object")
Reported-by: Jacob Moroni <jmoroni@google.com>
Closes: https://lore.kernel.org/all/CAHYDg1TOGxRGZrS69d4Y--Shj_DZv0nJuM73iHUBwBM70g_t3Q@mail.gmail.com
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
Implement support for the Silergy SY7758 6-channel High Efficiency LED
Driver used for backlight brightness control in the Ayaneo Pocket S2
dual-DSI panel.
Signed-off-by: KancyJoe <kancy2333@outlook.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Link: https://patch.msgid.link/20260529-topic-sm8650-ayaneo-pocket-s2-sy7758-v5-2-03aacd49747c@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The Asus Expertbook B9406CAA also has a Realtek device in the ACPI that
doesn't exist in the physical hardware. This confuses the machine driver
into attempting to create DAI links for the device. Add a quirk to
remove this device.
Closes: https://github.com/thesofproject/linux/issues/5828
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260630081132.3294488-1-ckeepax@opensource.cirrus.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Instead of sizing sruntime[] with a hardcoded SWRM_MAX_DAIS constant,
allocate it at probe time once the actual port count is known from
hardware. This removes the need to keep the constant in sync with
dt-binding limits and naturally supports any future port count increase.
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Assisted-by: Claude Sonnet 4.6
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260701193006.4113-3-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
find_first_zero_bit(mask, n) returns n (not n+1) when all bits are set,
so the guard `pn > maxport` is never true on exhaustion. The driver
would silently call set_bit(maxport, port_mask) and assign the
out-of-range port instead of returning -EBUSY. Fix the comparison to
`pn >= maxport`.
Fixes: 02efb49aa805 ("soundwire: qcom: add support for SoundWire controller")
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Assisted-by: Claude Sonnet 4.6
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260701193006.4113-2-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
dangling of_node pointer
In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a
reference on np, which is then assigned to pdev->dev.of_node. The
function immediately calls of_node_put(np), releasing the reference and
leaving pdev->dev.of_node as a dangling pointer.
Remove the of_node_put(np) call to let the device hold the reference.
Cc: stable@vger.kernel.org
Fixes: bc407334e9a6 ("regulator: as3722: add regulator driver for AMS AS3722")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260626160150.54291-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
