summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-03Merge tag 'amd-drm-fixes-7.2-2026-07-02' of ↵Dave Airlie
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
2026-07-03Merge tag 'drm-intel-fixes-2026-07-02' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Input validation fixes for BIOS and EDID (Jani) - Fix HDCP code buffer overflow and seq_num_v monotonic increase check (Jani) - Fix near-NULL deref in i915_active during GFP_ATOMIC exhaustion (Joonas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/akYLxDea3kEyHqJA@jlahtine-mobl
2026-07-02drm/xe: Add tile_count to xe_probed_infoGustavo Sousa
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>
2026-07-02drm/xe: Don't initialize tile_count in xe_info_init_early()Gustavo Sousa
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>
2026-07-02drm/xe: Add graphics/media IPs and their step info to xe_probed_infoGustavo Sousa
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>
2026-07-02drm/xe/tests: Set non-GMDID graphics step in xe_pci_fake_device_init()Gustavo Sousa
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>
2026-07-02drm/xe: Add platform-level step info to xe_probed_infoGustavo Sousa
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>
2026-07-02drm/xe/step: Make xe_step_platform_get() independent from xe->infoGustavo Sousa
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>
2026-07-02drm/xe: Add devid and revid to xe_probed_infoGustavo Sousa
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>
2026-07-02drm/xe/step: Pass xe_step_info to xe_step_*_get() functionsGustavo Sousa
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>
2026-07-02drm/xe: Add framework for info probingGustavo Sousa
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>
2026-07-02csky: Fix a4/a5 restoration in syscall trace pathHanlin Song
The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2 Fixes: e0bbb53843b5 ("csky: Fixup abiv2 syscall_trace break a4 & a5") Suggested-by: Guo Ren <guoren@kernel.org> Signed-off-by: Hanlin Song <pgeorge8929@gmail.com> Signed-off-by: Guo Ren (Alibaba DAMO Academy) <guoren@kernel.org>
2026-07-02wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_beginGaole Zhang
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>
2026-07-02wifi: ath6kl: fix use-after-free in aggr_reset_state()Daniel Hodges
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>
2026-07-02wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware requestCheng Yongkang
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>
2026-07-02io_uring/uring_cmd: fix uring_cmd.c commentsYang Xiuwei
Fix "concelable" -> "cancelable" in the comment above io_uring_cmd_mark_cancelable(), and fix the memory ordering comment in __io_uring_cmd_done() to reference io_do_iopoll() and ->iopoll_completed. Signed-off-by: Yang Xiuwei <yangxiuwei@kylinos.cn> Link: https://patch.msgid.link/20260702082937.3707134-3-yangxiuwei@kylinos.cn Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-02futex/requeue: Revert "Prevent NULL pointer dereference in remove_waiter() ↵Sebastian Andrzej Siewior
on self-deadlock"" The commit cited below should not have been merged. It attemted to fix an existing problem ansd thereby introduced new problems by keeping the pi_state in state Q_REQUEUE_PI_IN_PROGRESS and leaking it. Based on the commit description the intention was to handle the case when task_blocks_on_rt_mutex() returns -EDEADLK and the following remove_waiter() dereferences the NULL pointer in waiter->task. That is already handled by Davidlohr in commit 40a25d59e85b3 ("locking/rtmutex: Skip remove_waiter() when waiter is not enqueued") and requires no further acting. Revert the commit breaking the "waiter == owner" case again. Fixes: 74e144274af39 ("futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock") Reported-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260701131150.0Ijhq4Dw@linutronix.de Closes: https://lore.kernel.org/all/20260629020049.2082397-1-michael.bommarito@gmail.com
2026-07-02iio: imu: inv_icm45600: clamp the device-reported FIFO sample countBryam Vargas
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>
2026-07-02iio: accel: hid-sensor-accel-3d: Avoid race between callback setup and ↵Sanjay Chitroda
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>
2026-07-02iio: magnetometer: hid-sensor-magn-3d: Avoid race between callback setup and ↵Sanjay Chitroda
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>
2026-07-02iio: light: hid-sensor-als: Avoid race between callback setup and device ↵Sanjay Chitroda
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>
2026-07-02iio: light: hid-sensor-prox: Avoid race between callback setup and device ↵Sanjay Chitroda
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>
2026-07-02iio: pressure: hid-sensor-press: Avoid race between callback setup and ↵Sanjay Chitroda
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>
2026-07-02iio: gyro: hid-sensor-gyro-3d: Avoid race between callback setup and device ↵Sanjay Chitroda
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>
2026-07-02iio: orientation: hid-sensor-incl-3d: Avoid race between callback setup and ↵Sanjay Chitroda
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>
2026-07-02iio: orientation: hid-sensor-rotation: Avoid race between callback setup and ↵Sanjay Chitroda
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>
2026-07-02arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board supportJoe Sandom
The RB5gen2 is an embedded development platform for the QCS8550, based on the Snapdragon 8 Gen 2 SoC (SM8550). This change implements the main board, the vision mezzanine will be supported in a follow up patch. The main board has the following features: - Qualcomm Dragonwing QCS8550 SoC - Adreno GPU 740 - Spectra ISP - Adreno VPU 8550 - Adreno DPU 1295 - 1 x 1GbE Ethernet (USB Ethernet) - WIFI 7 + Bluetooth 5.4 - 1 x USB 2.0 Micro B (Debug) - 1 x USB 3.0 Type C (ADB, DP out) - 2 x USB 3.0 Type A - 1 x HDMI 1.4 Type A - 1 x DP 1.4 Type C - 2 x WSA8845 Speaker amplifiers - 2 x Speaker connectors - 1 x On Board PDM MIC - Accelerometer + Gyro Sensor - 96Boards compatible low-speed and high-speed connectors [1] - 7 x LED indicators (4 user, 2 radio, 1 power) - Buttons for power, volume up/down, force USB boot - 3 x Dip switches On-Board PMICs: - PMK8550 2.1 - PM8550 2.0 - PM8550VS 2.0 x4 - PM8550VE 2.0 - PM8550B 2.0 - PMR735D 2.0 - PM8010 1.1 x2 Product Page: [2] [1] https://www.96boards.org/specifications/ [2] https://www.thundercomm.com/product/qualcomm-rb5-gen-2-development-kit The default msi-map from sm8550.dtsi is deleted for both pcie0 and pcie1. The QPS615 PCIe switch on each port exposes more than two devices (1 USP + 3 DSPs), but Gunyah currently limits ITS device mappings to two per root complex to save memory. With msi-map present, the ITS MAPD command times out. Deleting msi-map causes the DWC controller to fall back to its internal iMSI-RX module, which handles MSIs without this limitation. Signed-off-by: Joe Sandom <jsandom@axon.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260420-rb5gen2-dts-v4-5-b461909c2de8@axon.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02dt-bindings: arm: qcom: document QCS8550 RB5Gen2 boardJoe Sandom
Document the Qualcomm RB5gen2 from Thundercomm based on the QCS8550 chipset from Qualcomm. [1] https://www.thundercomm.com/product/qualcomm-rb5-gen-2-development-kit/ Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Joe Sandom <jsandom@axon.com> Link: https://lore.kernel.org/r/20260420-rb5gen2-dts-v4-4-b461909c2de8@axon.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: sm8550: move IPA properties to SoC device treeJoe Sandom
Move qcom,gsi-loader and memory-region properties from individual board DTS files into the SoC DTSI, since these are common to all SM8550-based boards. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Joe Sandom <jsandom@axon.com> Link: https://lore.kernel.org/r/20260420-rb5gen2-dts-v4-3-b461909c2de8@axon.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: sm8550: add PCIe port labelsJoe Sandom
Add labels to the root port nodes (pcie0_port0, pcie1_port0) to allow board DTS files to reference them for adding endpoint devices to each pcie root port. Update the pcieport0 reference to pcie0_port0 in sm8550-hdk.dts and sm8550-qrd.dts to match the label rename in sm8550.dtsi. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Joe Sandom <jsandom@axon.com> Link: https://lore.kernel.org/r/20260420-rb5gen2-dts-v4-2-b461909c2de8@axon.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: sm8550: add PCIe MHI register regionsJoe Sandom
Add the MHI register regions to the pcie0 and pcie1 controller nodes to expose link power state transition counters (L0s/L1/L1.1/L1.2/L2) via debugfs. The PCIe host driver uses this region to read the link_transition_count from the MHI registers. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Joe Sandom <jsandom@axon.com> Link: https://lore.kernel.org/r/20260420-rb5gen2-dts-v4-1-b461909c2de8@axon.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: glymur: add IMEM and PIL regionsAnanthu C V
Add an IMEM on glymur which falls back to mmio-sram and define the PIL relocation info region as its child, for post mortem tools to locate the loaded remoteprocs. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260424-glymur-imem-v5-2-18ede63cf063@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02dt-bindings: sram: document glymur as compatibleAnanthu C V
Add compatible for Qualcomm's glymur IMEM, a block of sram which can fall back to mmio-sram. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260424-glymur-imem-v5-1-18ede63cf063@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: qcs6490-rb3gen2: Enable 4-lane DisplayPort Alt ModeMahadevan P
Add the mode-switch property to the QMP combo PHY so that mode-switch events are routed to it, allowing the PHY to enter DisplayPort Alternate Mode. Expand the DP data-lanes assignment from two to four lanes to make use of the full link bandwidth available in this configuration. Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260420-kodiak_4k-v1-1-83dfc66b8f06@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: lemans-evk: Enable secondary USB controller in host modeSwati Agarwal
Enable secondary USB controller in host mode on lemans EVK Platform. Secondary USB controller is connected to a Genesys Logic USB HUB GL3590 having 4 ports. The ports of hub that are present on lemans EVK standalone board are used as follows:- 1) port-1 is connected to HD3SS3220 Type-C port controller. 2) port-4 is used for the M.2 E key on corekit. Standard core kit uses UART for Bluetooth. This port is to be used only if user optionally replaces the WiFi card with the NFA765 chip which uses USB for Bluetooth. Remaining 2 ports will become functional when the interface plus mezzanine board is stacked on top of corekit: 3) port-2 is connected to another hub which is present on the mezz through which 4 type-A ports are connected. 4) port-3 is used for the M.2 B key for a 5G card when the mezz is connected. Secondary USB Controller ↓ GL3590 USB Hub (4 ports) | |-- Port 1 → HD3SS3220 Type‑C Port Controller → USB‑C Connector | |-- Port 2 → Mezzanine USB Hub (when mezz attached) | |-- Port 3 → M.2 B‑Key Slot (when mezz attached) | |-- Port 4 → M.2 E‑Key Slot (Default: BT via UART; USB only if NFA765 module is installed) Mark the second USB controller as host only capable and add the HD3SS3220 Type-C port controller along with Type-C connector for controlling vbus supply. Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260406110113.1709886-3-swati.agarwal@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: lemans-evk: Rename hd3ss3220_ instance for primary port ↵Swati Agarwal
controller Rename the hd3ss3220_ instance to improve clarity and simplify usage when adding a secondary port controller. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260406110113.1709886-2-swati.agarwal@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: hamoa: add audio PD remote heap regionEkansh Gupta
Reference the reserved memory region for audio PD dynamic loading and remote heap requirements. Add the required VMID list for memory ownership transfers. Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260418-hamoaaudio-v1-1-a92866f744a6@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: monaco-arduino-monza: add USB-C controller and connectorLoic Poulain
Add the Cypress USB Type-C controller and associated connector. The controller is connected over I2C12 and wired to the USB1 DWC3. The USB-C connector routes both high-speed and super-speed signals. Enable dual-role data and power over the USB-C connector. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260421101606.411335-1-loic.poulain@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: ipq9574: add pwm nodeGeorge Moussalem
Describe the PWM block on IPQ9574. Although PWM is in the TCSR area, make pwm its own node as simple-mfd has been removed from the bindings and as such hardware components should have its own node. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://lore.kernel.org/r/20260406-ipq-pwm-v21-6-6ed1e868e4c2@outlook.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: ipq5332: add pwm nodeGeorge Moussalem
Describe the PWM block on IPQ5332. Although PWM is in the TCSR area, make pwm its own node as simple-mfd has been removed from the bindings and as such hardware components should have its own node. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://lore.kernel.org/r/20260406-ipq-pwm-v21-5-6ed1e868e4c2@outlook.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: ipq5018: add pwm nodeGeorge Moussalem
Describe the PWM block on IPQ5018. Although PWM is in the TCSR area, make pwm its own node as simple-mfd has been removed from the bindings and as such hardware components should have its own node. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://lore.kernel.org/r/20260406-ipq-pwm-v21-4-6ed1e868e4c2@outlook.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: ipq6018: add pwm nodeDevi Priya
Describe the PWM block on IPQ6018. Although PWM is in the TCSR area, make pwm its own node as simple-mfd has been removed from the bindings and as such hardware components should have its own node. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Co-developed-by: Baruch Siach <baruch.siach@siklu.com> Signed-off-by: Baruch Siach <baruch.siach@siklu.com> Signed-off-by: Devi Priya <quic_devipriy@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://lore.kernel.org/r/20260406-ipq-pwm-v21-3-6ed1e868e4c2@outlook.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: sm6115-pro1x: Correct touchscreen GPIO flagsKrzysztof Kozlowski
IRQ_TYPE_xxx flags are not correct in the context of GPIO flags. These are simple defines so they could be used in DTS but they will not have the same meaning: IRQ_TYPE_LEVEL_LOW = 8 = GPIO_TRANSITORY. Correct the touchscreen irq-gpios to use proper flags, assuming the author of the code wanted similar logical behavior: IRQ_TYPE_LEVEL_LOW => GPIO_ACTIVE_LOW Fixes: e46b455e67f8 ("arm64: dts: qcom: sm6115-pro1x: Add Goodix Touchscreen") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260413090527.53000-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02arm64: dts: qcom: milos: Add IMEM nodeLuca Weiss
Add a node for the IMEM found on Milos, which contains pil-reloc-info and the modem tables for IPA, among others. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260410-milos-imem-v3-2-d215385fa5ab@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-02batman-adv: fix VLAN priority offsetSven Eckelmann
The batadv_skb_set_priority() receives an SKB with the inner ethernet header at position "offset". When it tries to extract the IPv4 and IPv6 header, it needs to skip the ethernet header to get access to the IP header. But for VLAN header, it performs the access with the struct vlan_ethhdr. This struct contains both both the ethernet header and the VLAN header. It is therefore incorrect to skip over the whole vlan_ethhdr size to get access to the vlan_ethhdr. Cc: stable@vger.kernel.org Fixes: c54f38c9aa22 ("batman-adv: set skb priority according to content") Signed-off-by: Sven Eckelmann <sven@narfation.org>
2026-07-02ASoC: Add Loongson-2K0300 I2S controller and sound card supportMark Brown
Binbin Zhou <zhoubinbin@loongson.cn> says: This series adds ASoC support for the Loongson-2K0300 SoC and its associated development boards, including the CTCISZ Forever Pi and the ATK-DL2K0300B. Key changes: - Extend DT bindings to support ls2k0300-i2s and new audio card compatibles. - Refactor the platform I2S driver to handle SoC differences via per-device configuration (rev_id, optional APB DMA config, reset sequence). - Refactor the audio machine driver to support board-specific DAI formats, GPIO-based headphone detection/control, speaker enable, and DAPM routing. - Add jack detection and automatic switching between headphones and speakers for the DL2K0300B board. The patchset also cleans up the existing audio card binding by referencing the common sound-card properties, and adds new compatibles for the Loongson-2K0300 variants with proper DAI format handling. All changes have been tested on Loongson-2K2000 (PCI), Loongson-2K0300 Forever Pi and Loongson-2K0300 DL2K0300B boards. Link: https://patch.msgid.link/cover.1782439646.git.zhoubinbin@loongson.cn
2026-07-02ASoC: es8328: Add DAPM routes from MIC inputs to Mic BiasBinbin Zhou
The ES8328 codec has differential/single-ended microphone inputs (LINPUT1/RINPUT1, LINPUT2/RINPUT2) that require connection to the internal Mic Bias generator for proper operation. Currently, these routes are missing, which can cause microphone recording to fail. Add the missing DAPM routes to link the input pins to the Mic Bias supply, ensuring the microphone bias voltage is correctly applied. Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Link: https://patch.msgid.link/dcf1f8ae4f1f192a1d63e9fe7044b0218119b5eb.1782439646.git.zhoubinbin@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-02ASoC: loongson: Add headphone jack detection and DAPM routingBinbin Zhou
Extend the Loongson audio machine driver with jack detection, DAPM widgets support, enabling proper switching between headphones and speakers on the Loongson-2K0300 ATK-DL2K0300B board. Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Link: https://patch.msgid.link/c4b1503220b6fb433ecdcb881556827579041c3d.1782439646.git.zhoubinbin@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-02ASoC: dt-bindings: loongson,ls-audio-card: Add ATK-DL2K0300B compatibleBinbin Zhou
Add new compatible for the ATK-DL2K0300B development board based on Loongson-2K0300. Unlike others, this board features GPIO-controlled headphone detection, headphone control, and speaker enable. Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Link: https://patch.msgid.link/71430fcee5951fb7a7d52e2091a87707db85e06c.1782439646.git.zhoubinbin@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-02ASoC: loongson: Add Loongson-2K0300 CTCISZ Forever Pi sound card supportBinbin Zhou
The Loongson-2K0300 audio card uses a different DAI format compared to existing Loongson platforms. Move the dai_fmt setting from the static DAI link to runtime hw_params via snd_soc_runtime_set_dai_fmt(), and pass the correct format through driver match data. Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Link: https://patch.msgid.link/ed1314e1d3275fd20aff47397345a88fad6e9368.1782439646.git.zhoubinbin@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-22 04:30:41 +0000