summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
13 daysdrm/i915/display: Move CMRR crtc_state members under VRRMitul Golani
Move CMRR crtc state members under VRR infrastructure as it is enabled during fixed-refresh-rate VRR timing generator is enabled. --v2: - Move cmrr structure under vrr umbrella. - Remove dups. (Jani) --v3: - Update commit message Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260730105919.3913412-6-mitulkumar.ajitkumar.golani@intel.com
13 daysdrm/i915/vrr: Update AS_SDP target_rr_divider based on CMRR config requestMitul Golani
Compute AS_SDP target_rr_divider based on actual CMRR request requirement. Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260730105919.3913412-5-mitulkumar.ajitkumar.golani@intel.com
13 daysdrm/i915/vrr: Add per-CRTC vrr/cmrr debugfs controlMitul Golani
Add a per-CRTC debugfs file 'intel_vrr_target_refresh_rate' that lets the user force a CMRR target refresh rate and video-mode requirement. The file uses a "numerator/denominator" format: - numerator: requested refresh rate in milli-Hz (refresh rate in Hz * 1000, e.g. 60000 for 60 Hz) - denominator: 1000 for a 1:1 ratio (no video timing) or 1001 for the 1000/1001 video timing Reading the file reports the currently stored values; writing updates them. The file is created only on platforms with VRR and CMRR support. --v2: - Drop the "vrr" debugfs subdirectory and expose a single flat, intel_-prefixed "intel_vrr_cmrr" file (Jani, Nikula) - Rename struct intel_crtc.cmrr to force_cmrr to make its purpose explicit (Chaitanya) - Fix parse comment: numerator unit is milli-Hz, not KHz (Chaitanya) - Add debugfs/intel_ prefixes to the debugfs handler functions (Chaitanya) - Expand commit message with debugfs entry semantics (Chaitanya) --v3: - Rename debugfs function and file name (Chaitanya) - Remove railing new line at EOF (Chaitanya) - Update CMRR guard conditions (Chaitanya) - Add 0/0 default case. (Ramanaidu) --v4: - Correct CMRR guard check while creating debugfs --v5: - Commit message update (Chaitanya) - Add support for 0/0 writing (Validation) Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260730105919.3913412-4-mitulkumar.ajitkumar.golani@intel.com
13 daysdrm/i915/vrr: Restrict CMRR enable condition to VRR-TG-default platformsMitul Golani
CMRR is currently advertised on all HAS_CMRR platforms, but it depends on the VRR timing generator being the default timing generator, which currently only applies to DISPLAY_VER >= 30. Gate the CMRR enable condition and readout accordingly so CMRR is only reported on supported platforms. No functional change. --v2: - Create a separate function to check if CMRR possible --v3: - Simplify commit message (Chaitanya) - Remove redundant outer parenthesis (Chaitanya) Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260730105919.3913412-3-mitulkumar.ajitkumar.golani@intel.com
13 daysdrm/i915/psr: Do not enable PSR2 when CMRR is enabledMitul Golani
CMRR is mutually exclusive to PSR2, do not enable PSR2 when CMRR is enabled. --v2: - Restrict selective update config check (Ankit) - Commit message change --v3: - Commit changes --v4: - Add check to psr2_config_valid (Jouni) --v5: - Correct debug message --v6: - Commit message update Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260730105919.3913412-2-mitulkumar.ajitkumar.golani@intel.com
13 daysdrm/xe/oa: Extend OAM unit hwe assignment for new dGfxAshutosh Dixit
dGfx vecs hwe's for media version 35.00 and later follow the same assignment to OAM units as vcs engines. Bspec: 77977 Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260729230645.3052178-3-ashutosh.dixit@intel.com
13 daysdrm/xe/mcr: Take vcs1/vecs1 into account for first media sliceAshutosh Dixit
vcs1 and vecs1 may also be present on the first media slice, so take vcs1/vecs1 also into account when determining if the first media slice is absent. Bspec: 67103, 77977 Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260729230645.3052178-2-ashutosh.dixit@intel.com
13 daysfirmware: coreboot: Validate table boundsLaxman Acharya Padhya
The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table. Fixes: d384d6f43d1e ("firmware: google memconsole: Add coreboot support") Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com> Link: https://lore.kernel.org/r/20260801165651.42172-1-acharyalaxman8848@gmail.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
13 daysInput: samsung-keypad - use pm_runtime_active guardDmitry Torokhov
Simplify the driver by using the block-scope guard(pm_runtime_active) instead of manually invoking pm_runtime_get_sync() and pm_runtime_put(). Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260713-samsung-kp-irq-v2-3-acc84b6daf9a@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
13 daysInput: samsung-keypad - keep interrupt disabled while closedDmitry Torokhov
The driver requests the interrupt during probe, which by default enables it. If the bootloader left the keypad interrupts enabled, or if a spurious interrupt fires early before the driver is fully initialized and clocks are enabled, the interrupt handler will attempt to read registers and may cause a synchronous external abort. Fix this by requesting the interrupt with IRQF_NO_AUTOEN, keeping it disabled during probe. Enable the interrupt in samsung_keypad_start() when the device is opened and ready, and disable it in samsung_keypad_stop() when the device is closed. Remove the redundant re-enabling of the interrupt at the end of samsung_keypad_stop(). Additionally, manually clear the pending interrupt status during system resume when the device is closed to avoid immediate resume. Fixes: 0fffed27f92d ("Input: samsung-keypad - Add samsung keypad driver") Assisted-by: Antigravity:gemini-3.1-pro Link: https://patch.msgid.link/20260713-samsung-kp-irq-v2-2-acc84b6daf9a@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
13 daysInput: samsung-keypad - clean up wakeup configuration logicDmitry Torokhov
When checking if the device can wake the system, we should pull the device_may_wakeup() check to the caller instead of repeating it inside the toggle_wakeup() handler. Furthermore, when configuring the wakeup, we should safely ensure we write to the registers in the correct order: configure the interrupt receiver before enabling the peripheral's wake functionality, and vice-versa. Assisted-by: Antigravity:gemini-3.1-pro Link: https://patch.msgid.link/20260713-samsung-kp-irq-v2-1-acc84b6daf9a@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
13 daysInput: focaltech - fix array out-of-bounds in focaltech_process_rel_packetRichard Davies
Make finger2 (and also finger1) unsigned, so that if the finger index in the packet is 0 then subtracting 1 creates an array index which overflows above the existing check for FOC_MAX_FINGERS, as the existing comment says it should, instead of writing to state->fingers[-1]. Fixes: 05be1d079ec0 ("Input: psmouse - support for the FocalTech PS/2 protocol extensions") Signed-off-by: Richard Davies <richard@arachsys.com> Link: https://patch.msgid.link/20260701190932.14960-1-richard@arachsys.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
13 daysInput: atkbd - skip deactivate for HONOR ZQC-PDonglin Lyu
The internal keyboard on the HONOR ZQC-P (HONOR MagicBook Pro 14 2026) does not work after boot. Using the kernel command line 'i8042.dumbkbd=1' makes the keyboard functional, but the CapsLock LED does not work. Adding the 'atkbd_deactivate_fixup' quirk fixes the keyboard and CapsLock LED natively without requiring boot parameters. DMI: HONOR ZQC-P/ZQC-P-PCB, BIOS 1.09 03/19/2026 Fixes: 9cf6e24c9fbf ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID") Signed-off-by: Donglin Lyu <donglin_lyu@outlook.com> Tested-by: Ruslan Shevchenko <adefka@gmail.com> Link: https://patch.msgid.link/20260801151115.52709-1-donglin_lyu@outlook.com Cc: stable@vger.kernel.org [dtor: keep all HONOR entries together] Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
13 daysInput: atkbd - skip deactivate for Xiaomi Book Pro 14's internal keyboardZhefu Zhang
The internal keyboard of the Xiaomi Book Pro 14 does not work unless atkbd skips deactivating it at the end of atkbd_probe(). Using 'i8042.dumbkbd=1' also makes the keyboard work, but then the driver never writes to the keyboard at all, so the Caps Lock LED is lost. The atkbd_deactivate_fixup quirk fixes both without a boot parameter. DMI: XIAOMI Xiaomi Book Pro 14/TM2424, BIOS XMAPT4B0P0909 05/06/2026 Signed-off-by: Zhefu Zhang <a723356@gmail.com> Reviewed-by: Andrew Zhou <zhoulol888@gmail.com> Link: https://patch.msgid.link/20260802031559.19701-1-a723356@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
13 daysdrm/v3d: Serialize the scheduler timeout handlersMaíra Canal
V3D exposes several independent hardware queues (BIN, RENDER, TFU and CSD) but has only a single, global reset. A timeout on any one queue therefore has to stop, reset and restart the schedulers of every other queue as well. That makes concurrent timeout handlers unsafe. `reset_lock` was never able to make them safe, as a driver-side lock can only cover the driver's &drm_sched_backend_ops.timedout_job callback. The scheduler handles the timed out job and its pending list around that callback, outside of the driver's control, so a global reset triggered by one queue can still interfere with another queue that is in the middle of handling a timeout of its own. Consequently, if a reset happens in the CSD queue while a CL-intensive application is running, the global reset stops and restarts the CL queue's scheduler while that queue is handling a timeout of its own. As drm_sched_stop() and drm_sched_start() subtract and add the credits of every job sitting on the pending list of the scheduler they are called on, and as the CL queue's handler concurrently takes its job off that same list and puts it back, the stop and the start no longer see the same set of jobs. The CL queue is left with more credits in flight than its limit: [ 327.302739] ------------[ cut here ]------------ [ 327.302744] WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] [ 327.302884] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.18.39-v8-16k+ #3 PREEMPT [ 327.302889] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 327.302893] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched] [ 327.302984] Call trace: [ 327.302987] drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] (P) [ 327.302997] process_scheduled_works+0x180/0x3d0 [ 327.303010] worker_thread+0x268/0x3e8 [ 327.303016] kthread+0x140/0x250 [ 327.303022] ret_from_fork+0x10/0x20 [ 327.303031] ---[ end trace 0000000000000000 ]--- From that point on, the credit count of the CL queue is broken, causing a complete GPU hang and UI freeze. The DRM scheduler already provides a mechanism to serialize the timeout handlers of different schedulers: an ordered workqueue passed as drm_sched_init()'s @timeout_wq parameter. By default, each scheduler queues its timeout work on the system workqueue, which runs the handlers concurrently. Give all of the queues a shared ordered workqueue instead, as recommended by the DRM scheduler documentation for hardware that has distinct queues but resets globally. Cc: stable@vger.kernel.org # 6.15 Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260728-v3d-order-global-reset-v1-1-e47be838158d@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
13 daysMerge tag 's390-7.2-6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 updates from Vasily Gorbik: - Fix PCI MMIO write syscall falsely reporting success for mappings not valid for MMIO when MIO is unavailable by returning -EFAULT - Fix CPRB parameter buffer overflows in zcrypt CCA AES cipher and ECC private key conversion by rejecting oversized key tokens - Fix buffer overreads and length underflow in pkey and zcrypt CCA token validation by checking length fields against actual buffer sizes - Fix out of bounds permission bitmap access in zcrypt EP11 admin CPRB filtering on custom device nodes by using AP_DOMAINS as the limit - Fix speculative permission bitmap reads in zcrypt CCA and EP11 admin CPRB handling by sanitizing user controlled domain indexes - Fix sensitive key material left in zcrypt CCA clear key import buffers by scrubbing CPRB and temporary buffers after use * tag 's390-7.2-6' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() s390/zcrypt: Close speculative mem read possibility s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs s390/zcrypt: Fix buffer over-read in cca_cipher2protkey s390/zcrypt: Validate length for CCA ECC private key requests s390/zcrypt: Validate length for CCA AES cipher key requests s390/pci: Fix s390_pci_mmio_write syscall error return without MIO
13 dayswifi: brcmfmac: fix P2P action frame handling without device vifJason Huang
Some P2P action frame paths assume the P2P device vif is always available. That is not true when userspace sends non-P2P public action frames through the primary interface, or when action-frame abort runs after the P2P device vif has not been created. Fall back to the primary vif when aborting an action frame without a P2P device vif, and guard P2P device saved IE access before using it for peer channel search. Fixes: 30fb1b272909 ("brcmfmac: use actframe_abort to cancel ongoing action frame") Fixes: 6eda4e2c5425 ("brcmfmac: Add tx p2p off-channel support.") Signed-off-by: Jason Huang <jason.huang2@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260722082608.412472-1-Jason.Huang2@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
13 dayswifi: brcmfmac: Set DMA direction for msgbuf packet IDsCan Peng
brcmf_msgbuf_init_pktids() takes the DMA direction from its callers, but never stores it in the packet ID state. Since the state is zeroed, pktids->direction remains DMA_BIDIRECTIONAL for both the TX and RX packet ID pools. All msgbuf packet ID map and unmap paths use pktids->direction. As a result, TX buffers requested with DMA_TO_DEVICE and RX buffers requested with DMA_FROM_DEVICE are mapped and unmapped as DMA_BIDIRECTIONAL instead. Store the caller-provided direction when initializing the packet ID state. Signed-off-by: Can Peng <pengcan@kylinos.cn> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260724092530.674624-1-pengcan@kylinos.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
13 dayswifi: brcmfmac: validate msgbuf flowring IDs before useCan Peng
Firmware messages carry flow_ring_id values which brcmfmac converts to an internal flowid by subtracting BRCMF_H2D_MSGRING_FLOWRING_IDSTART. The resulting value is used as a bit index in txstatus_done_map and as an array index into msgbuf->flowrings and the flowring state. Validate the firmware supplied flow_ring_id before using it. This prevents flow_ring_id values below BRCMF_H2D_MSGRING_FLOWRING_IDSTART from underflowing and rejects values outside msgbuf->max_flowrings. In the tx status path, complete the packet with an error after removing a valid packet id so the skb is not leaked when the flow ring id is invalid. Signed-off-by: Can Peng <pengcan@kylinos.cn> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260723055618.550834-1-pengcan@kylinos.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
13 daysMerge tag 'rtw-next-2026-08-02' of https://github.com/pkshih/rtwJohannes Berg
Ping-Ke Shih says: ================== rtw-next patches for v7.3 Some random cleanups and fixes on rtlwifi, rtw88 and rtw89. The major features added to rtw89 are listed: rtw89: - add LED support - update BT-coexistence mechanism to support dual Bluetooth for RTL8922D - support WiFi 7 chip RTL8922DE ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
13 daysMerge tag 'mt76-next-2026-08-01' of https://github.com/nbd168/wirelessJohannes Berg
Felix Fietkau says: =================== mt76 patches for 7.3 - fixes - mt7925 NAN support - mt7928 support - mt7996 AP powersave improvements =================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
13 daysMerge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley" "No core changes. The largest driver fix is the reversion of threaded interrupt handlers in UFS and the next is the resume deadlock fix in hisi_sas which extends into libsas" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: core: Initialize hba->rpmbs list in ufshcd scsi: mpi3mr: Fix potential deadlock in mpi3mr_fault_uevent_emit scsi: target: Clear cmd_cnt when initial counter enrollment fails scsi: zfcp: Fix memory leak during adapter release by destroying gid_pn_req scsi: ufs: core: Revert "Delegate the interrupt service routine to a threaded IRQ handler" scsi: ufs: core: Cancel RTC work in active-active suspend scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE scsi: ufs: dt-bindings: Add missing mcq reg for qcom,sa8255p-ufshc scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer
13 daysMerge tag 'mm81x-next-2026-07-31' of ↵Johannes Berg
https://github.com/MorseMicroLabs/linux-wireless Lachlan Hodges says: ==================== - Just a single fix for synchronously shutting down timers to prevent a UaF. ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
13 dayswifi: wilc1000: validate monitor transmit frame headersMariano Baragiola
wilc_wfi_mon_xmit() reads the radiotap length before ensuring that the fixed header is present. After stripping that header, it reads the frame type and all three 802.11 addresses without checking how much frame data remains. A truncated monitor injection can therefore cause out-of-bounds reads. Validate the radiotap header first, use the common 802.11 helper to check the variable header length, and require a complete three-address header before using the addresses. This covers QoS and four-address data headers while rejecting short control headers that this path cannot classify. Signed-off-by: Mariano Baragiola <mbaragiola@linux.com> Link: https://patch.msgid.link/20260728192610.2236361-1-mbaragiola@linux.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
13 dayswifi: zd1211rw: reject secondary interfaces to prevent conflictsSlawomir Stepien
The zd1211rw driver is designed for single-function Wi-Fi dongles and hardcodes its USB endpoints. When a malformed USB device exposes multiple interfaces that match the driver's device ID, the driver blindly binds to all of them. During probe(), the driver calls usb_reset_device(), which iterates over all interfaces and invokes the pre_reset() callback for each bound interface. Since multiple interfaces are bound to zd1211rw, pre_reset() is called sequentially for each instance, acquiring their respective &mac->chip.mutex. Because all instances initialize their mutexes with the same lock class, lockdep detects a task acquiring a lock of the same class it already holds and flags it as a possible recursive deadlock: WARNING: possible recursive locking detected kworker/0:1/11 is trying to acquire lock: ffff88810371dde0 (&chip->mutex){+.+.}-{4:4}, at: zd_chip_disable_rxtx+0x20/0x50 drivers/net/wireless/zydas/zd1211rw/zd_chip.c:1465 but task is already holding lock: ffff8881138ddde0 (&chip->mutex){+.+.}-{4:4}, at: pre_reset+0x28c/0x380 drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1505 Fix this by explicitly rejecting secondary interfaces (bInterfaceNumber != 0) during probe(). This ensures that only a single instance of the driver binds to the device, eliminating the recursive locking scenario. Fixes: e85d0918b54f ("[PATCH] ZyDAS ZD1211 USB-WLAN driver") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+0ec3d1a6cf1fbe79c153@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0ec3d1a6cf1fbe79c153 Link: https://syzkaller.appspot.com/ai_job?id=00724ef7-fd77-4cde-9779-895b8f63c2f6 Signed-off-by: Slawomir Stepien <sst@poczta.fm> Link: https://patch.msgid.link/20260730065231.1644030-1-sst@poczta.fm Signed-off-by: Johannes Berg <johannes.berg@intel.com>
13 daysMerge tag 'dmaengine-fix-7.2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine Pull dmaengine fixes from Vinod Koul: - switchtec fix for register programming - sun6i descriptor reclaim fix - Intel idxd fixes for double free in error and setup failure - Qualcomm bam dma command element fix * tag 'dmaengine-fix-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: dmaengine: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+ dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open() dmaengine: idxd: fix double free of wq, engine, and group structs dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA dmaengine: switchtec-dma: fix FIELD_GET misuse when programming SE threshold
13 daysMerge tag 'phy-fixes-7.2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy Pull phy fixes from Vinod Koul: - fixes for zynqmp clock and pm error handling and SERDES scrambler register handling - Rockchip SSC spread fix - Qualcomm musb return call fix * tag 'phy-fixes-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB phy: zynqmp: use read-modify-write for SERDES scrambler bypass phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask phy: zynqmp: fix runtime PM leak on probe allocation failure phy: zynqmp: fix clock error handling in xpsgtr_phy_init() phy: rockchip: naneng-combphy: Always configure SSC spread direction phy: qcom: m31-eusb2: Fix return value of init call
14 dayswifi: nxpwifi: embed rx_reorder_ptrRosen Penev
rx_reorder_ptr is a dynamically allocated array which is done near the main struct allocation. Combine the two to avoid freeing separately. Also fix the type to what it actually is. void is normally used to avoid casting but there's no need here. Signed-off-by: Rosen Penev <rosenp@gmail.com> Tested-by: Jeff Chen <jeff.chen_1@nxp.com> Reviewed-by: Jeff Chen <jeff.chen_1@nxp.com> Link: https://patch.msgid.link/20260729183715.691287-1-rosenp@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
14 dayswifi: cfg80211: convert cookie output to input parameterArend van Spriel
The remain_on_channel, mgmt_tx, and probe_peer ops previously used a u64 *cookie output parameter. Now that cfg80211 pre-assigns the cookie value before invoking drivers, the parameter conveys a value from caller to driver, not the other way around. Convert it to a plain u64 input parameter across the ops struct (cfg80211.h), rdev-ops.h wrappers, nl80211.c/mlme.c call sites, mac80211, and all driver implementations. The tx_control_port op is excluded: its cookie pointer is nullable (passed as NULL when dont_wait_for_ack is set), so the nullable pointer semantics are still required. Internal mac80211 helpers ieee80211_start_roc_work() and ieee80211_attach_ack_skb() still take u64 *cookie because they assign to the pointee; their callers now pass &cookie to take the address of the local value parameter. wil6210's internal wil_p2p_listen() is also updated to take u64 cookie since it is called directly from the remain_on_channel callback. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-12-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
14 dayswifi: rtl8723bs: use pre-assigned cookie for mgmt_txArend van Spriel
Stop using params->buf address as cookie value and simply pass the pre-assigned cookie in frame tx status. This implementation seems to fire-and-forget the transmitted frame as the cookie is not used in any other way. Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-11-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
14 dayswifi: qtnfmac: use pre-assigned cookie for mgmt_txArend van Spriel
Stop overwriting *cookie with a random value in qtnf_mgmt_tx(). The internal firmware frame identifier (short_cookie) is unchanged. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-10-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
14 dayswifi: nxpwifi: use pre-assigned cookie for remain_on_channel and mgmt_txArend van Spriel
Stop calling nxpwifi_roc_cookie() to generate cookies in nxpwifi_cfg80211_remain_on_channel() and nxpwifi_cfg80211_mgmt_tx(). Use the pre-assigned cookie from cfg80211 instead. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-9-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
14 dayswifi: wilc1000: use pre-assigned cookie for remain_on_channel and mgmt_txArend van Spriel
Stop generating cookies by incrementing inc_roc_cookie in remain_on_channel() and via get_random_u32() in mgmt_tx(). Use the pre-assigned cookie from cfg80211 instead. Remove the now-unused id local variable from remain_on_channel(). Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-8-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
14 dayswifi: mwifiex: use pre-assigned cookie for remain_on_channel and mgmt_txArend van Spriel
Stop generating cookies via get_random_u32() in mwifiex_cfg80211_remain_on_channel() and mwifiex_cfg80211_mgmt_tx(). Use the pre-assigned cookie from cfg80211 instead. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-7-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
14 dayswifi: brcmfmac: use pre-assigned cookie for remain_on_channel and mgmt_txArend van Spriel
Stop generating cookies in brcmf_p2p_remain_on_channel() and brcmf_cfg80211_mgmt_tx(). For remain_on_channel, remove the cookie increment from brcmf_p2p_discover_listen() and store the pre-assigned cookie in p2p->remain_on_channel_cookie. The expiry callback in brcmf_p2p_notify_listen_complete() already reads from that field. For mgmt_tx, remove the "*cookie = 0" assignments in brcmf_cfg80211_mgmt_tx() and the cyw extension. The pre-assigned cookie is then correctly passed to cfg80211_mgmt_tx_status() which already uses *cookie. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-6-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
14 dayswifi: wil6210: use pre-assigned cookie for remain_on_channel, mgmt_tx and ↵Arend van Spriel
probe_peer Stop overwriting the pre-assigned cookie in wil_p2p_listen(), wil_cfg80211_mgmt_tx(), and wil_cfg80211_probe_peer(). For remain_on_channel, store the pre-assigned cookie in p2p->cookie instead of incrementing it. All cancel and expiry callbacks already read from p2p->cookie so they pick up the correct value. For mgmt_tx, remove the defensive "cookie ? *cookie : 0" guard; cfg80211 guarantees a non-NULL cookie pointer. For probe_peer, store the pre-assigned cookie in req->cookie instead of the CID value. The CID is still available via req->cid for STA lookup in wil_probe_client_handle(). Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-5-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
14 dayswifi: ath6kl: use pre-assigned cookie for remain_on_channel and mgmt_txArend van Spriel
Stop generating cookies in ath6kl_remain_on_channel() and ath6kl_mgmt_tx(). cfg80211 now pre-assigns the cookie before calling into the driver. For remain_on_channel, store the pre-assigned cookie in vif->last_roc_id. Widen last_roc_id and last_cancel_roc_id from u32 to u64 to hold the full 64-bit cookie value. For mgmt_tx, store the pre-assigned cookie in wmi->last_mgmt_tx_cookie so the firmware TX status event handler can pass the correct cookie to cfg80211_mgmt_tx_status(). Thread the cookie through the powersave queue (ath6kl_mgmt_buff) so it is available when the frame is eventually dequeued and sent. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-4-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
14 dayscounter: ti-eqep: Remove redundant dev_err_probe()Pan Chuang
devm_request_threaded_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err_probe() call. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Reviewed-by: David Lechner <david@lechnology.com> Link: https://lore.kernel.org/r/20260715135030.326290-4-panchuang@vivo.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
14 dayscounter: ti-ecap-capture: Remove redundant dev_err_probe()Pan Chuang
devm_request_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err_probe() call. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Link: https://lore.kernel.org/r/20260715135030.326290-3-panchuang@vivo.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
14 dayscounter: stm32-timer-cnt: Remove redundant dev_err()Pan Chuang
devm_request_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Link: https://lore.kernel.org/r/20260715135030.326290-2-panchuang@vivo.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
14 dayscounter: microchip-tcb-capture: Fix DT channel validationBabanpreet Singh
mchp_tc_probe() reads the devicetree "reg" cell - a u32, per the API contract of of_property_read_u32_index() - into a signed int, so the bounds check "channel > 2" fails to reject cell values at or above 0x80000000: reinterpreted as a negative int, they compare below 2 and pass validation. A malformed devicetree can therefore drive a negative channel into the ATMEL_TC_REG() offset arithmetic, making the driver access syscon regmap offsets outside the TC block's register window, and into the "t%d_clk" clock-name formatting, where it truncates clk_name (sized for "t0_clk".."t2_clk"). Declare channel as u32, matching the API contract; the unsigned comparison then rejects everything except channels 0..2. Adjust the format specifier to %u accordingly, which also resolves the W=1 warning that exposed the gap: microchip-tcb-capture.c:520:56: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size 6 [-Wformat-truncation=] note: directive argument in the range [-2147483648, 2] No behavior change for well-formed devicetrees: channels 0..2 take identical paths before and after. Fixes: 106b104137fd ("counter: Add microchip TCB capture counter") Assisted-by: Claude:claude-fable-5 [gcc W=1] Signed-off-by: Babanpreet Singh <bbnpreetsingh@gmail.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Link: https://lore.kernel.org/r/20260714042910.7-1-bbnpreetsingh@gmail.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
14 daysperf: arm_pmu_acpi: Get rid of the edge-triggered interrupt oddityMarc Zyngier
The ACPI spec bizarrely indicates that the PMU interrupt can be edge-triggered, which contradicts the very basics of the PMU architecture (SW is required to clear the interrupt condition for the level to drop). Remove the code parsing this flag and always flag the interrupt as level triggered, no matter what firmware says. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
14 daysperf/arm_cspmu: Make IRQ more optionalRobin Murphy
If we have 64-bit counters, we can reasonably assume we'll never have to handle an overflow before the end of the universe (since we're a system PMU with no sampling). Thus even if firmware does specify an IRQ, we can still continue in the event of being unable to request it. This can help systems where IRQs cannot be claimed exclusively, or are broken in other ways. Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
14 daysperf/arm_cspmu: Improve sub-module error reportingRobin Murphy
When waiting for a sub-module to register, we return a bare -EPROBE_DEFER that ends up showing the end user: platform arm-cs-arch-pmu.1: deferred probe pending (no reason) wherein it's not necessarily clear that they might need to take some action to ensure the appropriate module is available to load. Let's use dev_err_probe() here so we can show exactly what we're waiting for. Similarly, in the case where something's gone horribly wrong with an already-registered module, we can use dev_WARN() to standardise the device/driver attribution rather than just open-coding "arm_cspmu". Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
14 daysperf/arm_cspmu: Improve APMT-based PMU namingRobin Murphy
On ACPI systems, it has not actually been possible for userspace to reliably tell which PMU corresponds to which APMT entry for types other than "ACPI device" - the evidence trail only leads from the arbitrarily-numbered PMU device to its arbitrarily-numbered parent platform device that has no distinguishing features either. While we've now improved the platform device creation to associate the actual APMT unique ID, we may as well also tweak the PMU devices to substitute the arbitrary number with a different arbitrary number that might be more directly meaningful based on the APMT definitions. We don't have an equivalent for Devicetree, but in that case the platform devices are at least identifiable via their sysfs-visible of_node. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> [will: Remove unneeded semicolon reported by coccinelle] Signed-off-by: Will Deacon <will@kernel.org>
14 daysACPI/APMT: Use stable device IDRobin Murphy
The APMT node format includes a unique identifier, so we can use this as the platform device ID to give userspace stable and identifiable device names, rather than auto numbering dependent on how the table is parsed. Cc: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: Hanjun Guo <guohanjun@huawei.com> Cc: Sudeep Holla <sudeep.holla@kernel.org> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
14 daysperf/cxlpmu: Support Channel/Rank/Bank filterHarshal Thakkar
Implement CRB filtering per CXL 4.0 8.2.7.2.2, and extend the current filtering support beyond HDM. CRB filtering is only permitted for the DDR Interface, Queue Occupancy, Queue Residency and Retry event groups (CXL 4.0 Table 13-5), and only when counting a single event (a single mask bit). Because these group IDs are scoped by the CXL vendor ID, events from other vendors are also rejected. For example, to count DDR activates on channel 2 only: perf stat -a -e cxl_pmu_mem0.0/ddr_act,crb_filter_en=1,crb=0x02FFFFFF/ Placing the 32-bit CRB value at config2:32-63 leaves the existing HDM value at config2:0-15 untouched and avoids needing a new config3. Signed-off-by: Harshal Thakkar <harshal.t@samsung.com> [davidlohr: multiple fixes] Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Reviewed-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Will Deacon <will@kernel.org>
14 daysperf/cxlpmu: Add missing CXL 4.0 eventsHarshal Thakkar
Add support for CXL 4.0 events that are exposed by the CPMU hardware but not present in the driver. Such events are defined in Table 13-5 of the spec. Signed-off-by: Harshal Thakkar <harshal.t@samsung.com> [davidlohr: add missing throttle and queue occupancy events] Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Reviewed-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Will Deacon <will@kernel.org>
14 daysperf/cxlpmu: Fix 64-bit write to 32-bit HDM filter registerDavidlohr Bueso
The HDM decoder filter configuration register is 32 bits wide, but the driver programs it with a 64-bit writeq(). The filter value never exceeds 32 bits, so the upper half of the write is always zero and lands in the adjacent Filter ID 1 (Channel/Rank/Bank) configuration register at offset+4. Fixes: 5d7107c72796 ("perf: CXL Performance Monitoring Unit driver") Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Reviewed-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Will Deacon <will@kernel.org>
14 daysiommu/arm-smmu-v3: Support IDR5.DS and widen the TLBI SCALE fieldNicolin Chen
An SMMU implementing SMMU_IDR5.DS extends the range invalidation commands: the SCALE field grows a 6th bit, raising its maximum value from 31 to 39, and TTL == 0b01 becomes a valid level hint for a 16KB translation granule. Add a new ARM_SMMU_FEAT_DS feature detecting the DS bit, and widen the CMDQ_TLBI_0_SCALE field to its architectural 6 bits. Mask the scale value explicitly in arm_smmu_cmdq_batch_add_range(), so the range invalidation path emits the same commands as before, keeping the pre-existing 5-bit truncation of a scale above 31. Also list DS as a valid IDR5 field in the iommu_hw_info_arm_smmuv3 kdoc: iommufd has always reported the raw IDR5 register, so a VMM may conclude from that bit alone that it can expose DS to its guest. Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Assisted-by: Claude:claude-fable-5 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>