summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-30platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacksKurt Borja
After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content. Reported-by: Jan Graczyk <jangraczyk@yahoo.ca> Closes: https://lore.kernel.org/r/CAHk-=wgMiSKXf7SvQrfEnxVtmT=QVQPjJdNjfm3aXS7wc=rzTw@mail.gmail.com/ Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Kurt Borja <kuurtb@gmail.com> Link: https://lore.kernel.org/r/20250630-sysman-fix-v2-1-d185674d0a30@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-30perf/core: Fix the WARN_ON_ONCE is out of lock protected regionLuo Gengkun
commit 3172fb986666 ("perf/core: Fix WARN in perf_cgroup_switch()") try to fix a concurrency problem between perf_cgroup_switch and perf_cgroup_event_disable. But it does not to move the WARN_ON_ONCE into lock-protected region, so the warning is still be triggered. Fixes: 3172fb986666 ("perf/core: Fix WARN in perf_cgroup_switch()") Signed-off-by: Luo Gengkun <luogengkun@huaweicloud.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20250626135403.2454105-1-luogengkun@huaweicloud.com
2025-06-30ALSA: usb-audio: Improve filtering of sample rates on Focusrite devicesAlexander Tsoy
Previously we were filtering out only upper unsupported sampling rates. This patch adds filtering of the lower unsupported sampling rates. As a result there is 1:1 mapping between altsetting and supported rates. The issue was found on a Scarlett 3rd Gen card (see linked bug), but the same filtering is likely needed for the Scarlett 1st and 2nd Gen as well as the older Clarett cards which lacks Valid Alternate Setting Control. Patch was not tested on a real hardware. Link: https://bugzilla.kernel.org/show_bug.cgi?id=214493 Signed-off-by: Alexander Tsoy <alexander@tsoy.me> Link: https://patch.msgid.link/20250630013357.1327420-1-alexander@tsoy.me Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-06-30riscv: cpu_ops_sbi: Use static array for boot_dataVivian Wang
Since commit 6b9f29b81b15 ("riscv: Enable pcpu page first chunk allocator"), if NUMA is enabled, the page percpu allocator may be used on very sparse configurations, or when requested on boot with percpu_alloc=page. In that case, percpu data gets put in the vmalloc area. However, sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data, and simply assumes that __pa() would work. This causes the just started hart to immediately access an invalid address and hang. Fortunately, struct sbi_hart_boot_data is not too large, so we can simply allocate an array for boot_data statically, putting it in the kernel image. This fixes NUMA=y SMP boot on Sophgo SG2042. To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then run with: qemu-system-riscv64 -M virt -smp 2 -nographic \ -kernel arch/riscv/boot/Image \ -append "percpu_alloc=page" Kernel output: [ 0.000000] Booting Linux on hartid 0 [ 0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025 ... [ 0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712 ... [ 0.083192] smp: Bringing up secondary CPUs ... [ 0.086722] ------------[ cut here ]------------ [ 0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080) [ 0.088001] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/physaddr.c:14 __virt_to_phys+0xae/0xe8 [ 0.088376] Modules linked in: [ 0.088656] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc1 #11 NONE [ 0.088833] Hardware name: riscv-virtio,qemu (DT) [ 0.088948] epc : __virt_to_phys+0xae/0xe8 [ 0.089001] ra : __virt_to_phys+0xae/0xe8 [ 0.089037] epc : ffffffff80021eaa ra : ffffffff80021eaa sp : ff2000000004bbc0 [ 0.089057] gp : ffffffff817f49c0 tp : ff60000001d60000 t0 : 5f6f745f74726976 [ 0.089076] t1 : 0000000000000076 t2 : 705f6f745f747269 s0 : ff2000000004bbe0 [ 0.089095] s1 : ff2000000001d080 a0 : 0000000000000000 a1 : 0000000000000000 [ 0.089113] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.089131] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000 [ 0.089155] s2 : ffffffff8130dc00 s3 : 0000000000000001 s4 : 0000000000000001 [ 0.089174] s5 : ffffffff8185eff8 s6 : ff2000007f1eb000 s7 : ffffffff8002a2ec [ 0.089193] s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000000 [ 0.089211] s11: 0000000000000000 t3 : ffffffff8180a9f7 t4 : ffffffff8180a9f7 [ 0.089960] t5 : ffffffff8180a9f8 t6 : ff2000000004b9d8 [ 0.089984] status: 0000000200000120 badaddr: ffffffff80021eaa cause: 0000000000000003 [ 0.090101] [<ffffffff80021eaa>] __virt_to_phys+0xae/0xe8 [ 0.090228] [<ffffffff8001d796>] sbi_cpu_start+0x6e/0xe8 [ 0.090247] [<ffffffff8001a5da>] __cpu_up+0x1e/0x8c [ 0.090260] [<ffffffff8002a32e>] bringup_cpu+0x42/0x258 [ 0.090277] [<ffffffff8002914c>] cpuhp_invoke_callback+0xe0/0x40c [ 0.090292] [<ffffffff800294e0>] __cpuhp_invoke_callback_range+0x68/0xfc [ 0.090320] [<ffffffff8002a96a>] _cpu_up+0x11a/0x244 [ 0.090334] [<ffffffff8002aae6>] cpu_up+0x52/0x90 [ 0.090384] [<ffffffff80c09350>] bringup_nonboot_cpus+0x78/0x118 [ 0.090411] [<ffffffff80c11060>] smp_init+0x34/0xb8 [ 0.090425] [<ffffffff80c01220>] kernel_init_freeable+0x148/0x2e4 [ 0.090442] [<ffffffff80b83802>] kernel_init+0x1e/0x14c [ 0.090455] [<ffffffff800124ca>] ret_from_fork_kernel+0xe/0xf0 [ 0.090471] [<ffffffff80b8d9c2>] ret_from_fork_kernel_asm+0x16/0x18 [ 0.090560] ---[ end trace 0000000000000000 ]--- [ 1.179875] CPU1: failed to come online [ 1.190324] smp: Brought up 1 node, 1 CPU Cc: stable@vger.kernel.org Reported-by: Han Gao <rabenda.cn@gmail.com> Fixes: 6b9f29b81b15 ("riscv: Enable pcpu page first chunk allocator") Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Tested-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20250624-riscv-hsm-boot-data-array-v1-1-50b5eeafbe61@iscas.ac.cn Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
2025-06-30riscv: Require clang-17 or newer for kCFINathan Chancellor
After the combination of commit c217157bcd1d ("riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS"), which starts using '-fpatchable-function-entry=M,N', and commit d0262e907e29 ("riscv: ftrace: support PREEMPT"), which allows CONFIG_DYNAMIC_FTRACE to be enabled by allmodconfig, allmodconfig builds with clang-16 begin crashing in the generic LLVM kCFI pass (see [1] for the stack trace). clang-17 avoids this crash by moving to target-specific lowering of the kCFI operand bundles [2]. Require clang-17 to select CONFIG_CFI_CLANG to avoid this crash. Fixes: c217157bcd1d ("riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS") Link: https://godbolt.org/z/xG39Pn16o [1] Link: https://github.com/llvm/llvm-project/commit/62fa708ceb027713b386c7e0efda994f8bdc27e2 [2] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20250612-riscv-require-clang-17-for-kcfi-v1-1-216f7cd7d87f@kernel.org Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
2025-06-30nvme-pci: refresh visible attrs after being checkedEugen Hristev
The sysfs attributes are registered early, but the driver does not know whether they are needed or not at that moment. For the CMB attributes, commit e917a849c3fc ("nvme-pci: refresh visible attrs for cmb attributes") solved this problem by calling nvme_update_attrs after mapping the CMB. However the issue persists for the HMB attributes. To solve the problem, moved the call to nvme_update_attrs after nvme_setup_host_mem, which sets up the HMB. Fixes: e917a849c3fc ("nvme-pci: refresh visible attrs for cmb attributes") Fixes: 86adbf0cdb9e ("nvme: simplify transport specific device attribute handling") Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Signed-off-by: André Almeida <andrealmeid@igalia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2025-06-30nvmet: fix memory leak of bio integrityDmitry Bogdanov
If nvmet receives commands with metadata there is a continuous memory leak of kmalloc-128 slab or more precisely bio->bi_integrity. Since commit bf4c89fc8797 ("block: don't call bio_uninit from bio_endio") each user of bio_init has to use bio_uninit as well. Otherwise the bio integrity is not getting free. Nvmet uses bio_init for inline bios. Uninit the inline bio to complete deallocation of integrity in bio. Fixes: bf4c89fc8797 ("block: don't call bio_uninit from bio_endio") Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2025-06-30nvme: correctly account for namespace head reference counterNilay Shroff
The blktests nvme/058 manifests an issue where the NVMe subsystem kobject entry remains stale in sysfs, causing a failure during subsequent NVMe module reloads[1]. Specifically, when attempting to register a new NVMe subsystem, the driver encounters a kobejct name collision because a stale kobject still exists. Though, please note that nvme/058 doesn't report any failure and test case passes and it's only during subsequent NVMe module reloads, the stale nvme sub- system kobject entry in sysfs causes the observed symptom[1]. This issue stems from an imbalance in the get/put usage of the namespace head (nshead) reference counter. The nshead holds a reference to the associated NVMe subsystem. If the nshead reference is not properly released, it prevents the cleanup of the subsystem's kobject, leaving nvme subsystem stale entry behind in sysfs. During the failure case, the last namespace path referencing a nshead is removed, but the nshead reference was not released. This occurs because the release logic currently only puts the nshead reference when its state is LIVE. However, in configurations where ANA (Asymmetric Namespace Access) is enabled, a namespace may be associated with an ANA state that is neither optimized nor non-optimized. In this case, the nshead may never transition to LIVE, and the corresponding nshead reference is then never dropped. In fact nvme/058 associates some of nvme namespaces to an inaccessible ANA state and with that nshead is created but it's state is not transitioned to LIVE. So the current logic would then causes nshead reference to be leaked for non-LIVE states. Another scenario, during namespace allocation, the driver first allocates a nshead and then issues an Identify Namespace command. If this command fails — which can happen in tests like nvme/058 that rapidly enables and disables namespaces — we must release the reference to the newly allocated nshead. However this reference release is currently missing in the failure, causing a nshead reference leak. To fix this, we now unconditionally release the nshead reference when the last nvme path referencing to the nshead is removed, regardless of the head’s state. Also during identify namespace failure case we now properly release the nshead reference. So this ensures proper cleanup of the nshead, and consequently, the NVMe subsystem and its associated kobject. This change prevents stale kobject entries from lingering in sysfs and eliminates the module reload failures observed just after running nvme/058. [1] https://lore.kernel.org/all/CAHj4cs8fOBS-eSjsd5LUBzy7faKXJtgLkCN+mDy_-ezCLLLq+Q@mail.gmail.com/ Reported-by: yi.zhang@redhat.com Closes: https://lore.kernel.org/all/CAHj4cs8fOBS-eSjsd5LUBzy7faKXJtgLkCN+mDy_-ezCLLLq+Q@mail.gmail.com/ Fixes: 62188639ec16 ("nvme-multipath: introduce delayed removal of the multipath head node") Tested-by: yi.zhang@redhat.com Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2025-06-30nvme: Fix incorrect cdw15 value in passthru error loggingAlok Tiwari
Fix an error in nvme_log_err_passthru() where cdw14 was incorrectly printed twice instead of cdw15. This fix ensures accurate logging of the full passthrough command payload. Fixes: 9f079dda1433 ("nvme: allow passthru cmd error logging") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2025-06-30drm/i915/dsi: Fix NULL pointer deref in vlv_dphy_param_init()Hans de Goede
Commit 77ba0b856225 ("drm/i915/dsi: convert vlv_dsi.[ch] to struct intel_display") added a to_intel_display(connector) call to vlv_dphy_param_init() but when vlv_dphy_param_init() gets called the connector object has not been initialized yet, so this leads to a NULL pointer deref: BUG: kernel NULL pointer dereference, address: 000000000000000c ... Hardware name: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS T100TA.314 08/13/2015 RIP: 0010:vlv_dsi_init+0x4e6/0x1600 [i915] ... Call Trace: <TASK> ? intel_step_name+0x4be8/0x5c30 [i915] intel_setup_outputs+0x2d6/0xbd0 [i915] intel_display_driver_probe_nogem+0x13f/0x220 [i915] i915_driver_probe+0x3d9/0xaf0 [i915] Use to_intel_display(&intel_dsi->base) instead to fix this. Fixes: 77ba0b856225 ("drm/i915/dsi: convert vlv_dsi.[ch] to struct intel_display") Signed-off-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250626143317.101706-1-hansg@kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 0dc6bfb50a5d0759e726cd36a3d3b7529fd2a627) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2025-06-30drm/i915/selftests: Change mock_request() to return error pointersDan Carpenter
There was an error pointer vs NULL bug in __igt_breadcrumbs_smoketest(). The __mock_request_alloc() function implements the smoketest->request_alloc() function pointer. It was supposed to return error pointers, but it propogates the NULL return from mock_request() so in the event of a failure, it would lead to a NULL pointer dereference. To fix this, change the mock_request() function to return error pointers and update all the callers to expect that. Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context interrupt tracking") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/685c1417.050a0220.696f5.5c05@mx.google.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 778fa8ad5f0f23397d045c7ebca048ce8def1c43) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2025-06-29Input: iqs7222 - explicitly define number of external channelsJeff LaBundy
The number of external channels is assumed to be a multiple of 10, but this is not the case for IQS7222D. As a result, some CRx pins are wrongly prevented from being assigned to some channels. Address this problem by explicitly defining the number of external channels for cases in which the number of external channels is not equal to the total number of available channels. Fixes: dd24e202ac72 ("Input: iqs7222 - add support for Azoteq IQS7222D") Signed-off-by: Jeff LaBundy <jeff@labundy.com> Link: https://lore.kernel.org/r/aGHVf6HkyFZrzTPy@nixie71 Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-06-29io_uring: gate REQ_F_ISREG on !S_ANON_INODE as wellJens Axboe
io_uring marks a request as dealing with a regular file on S_ISREG. This drives things like retries on short reads or writes, which is generally not expected on a regular file (or bdev). Applications tend to not expect that, so io_uring tries hard to ensure it doesn't deliver short IO on regular files. However, a recent commit added S_IFREG to anonymous inodes. When io_uring is used to read from various things that are backed by anon inodes, like eventfd, timerfd, etc, then it'll now all of a sudden wait for more data when rather than deliver what was read or written in a single operation. This breaks applications that issue reads on anon inodes, if they ask for more data than a single read delivers. Add a check for !S_ANON_INODE as well before setting REQ_F_ISREG to prevent that. Cc: Christian Brauner <brauner@kernel.org> Cc: stable@vger.kernel.org Link: https://github.com/ghostty-org/ghostty/discussions/7720 Fixes: cfd86ef7e8e7 ("anon_inode: use a proper mode internally") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-06-29smb: client: fix readdir returning wrong type with POSIX extensionsPhilipp Kerling
When SMB 3.1.1 POSIX Extensions are negotiated, userspace applications using readdir() or getdents() calls without stat() on each individual file (such as a simple "ls" or "find") would misidentify file types and exhibit strange behavior such as not descending into directories. The reason for this behavior is an oversight in the cifs_posix_to_fattr conversion function. Instead of extracting the entry type for cf_dtype from the properly converted cf_mode field, it tries to extract the type from the PDU. While the wire representation of the entry mode is similar in structure to POSIX stat(), the assignments of the entry types are different. Applying the S_DT macro to cf_mode instead yields the correct result. This is also what the equivalent function smb311_posix_info_to_fattr in inode.c already does for stat() etc.; which is why "ls -l" would give the correct file type but "ls" would not (as identified by the colors). Cc: stable@vger.kernel.org Signed-off-by: Philipp Kerling <pkerling@casix.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-06-29spi: spi-fsl-dspi: Clear completion counter before initiating transferJames Clark
In target mode, extra interrupts can be received between the end of a transfer and halting the module if the host continues sending more data. If the interrupt from this occurs after the reinit_completion() then the completion counter is left at a non-zero value. The next unrelated transfer initiated by userspace will then complete immediately without waiting for the interrupt or writing to the RX buffer. Fix it by resetting the counter before the transfer so that lingering values are cleared. This is done after clearing the FIFOs and the status register but before the transfer is initiated, so no interrupts should be received at this point resulting in other race conditions. Fixes: 4f5ee75ea171 ("spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completion") Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250627-james-nxp-spi-dma-v4-1-178dba20c120@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-29spi: Raise limit on number of chip selects to 24Marc Kleine-Budde
We have a system which uses 24 SPI chip selects, raise the hard coded limit accordingly. Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://patch.msgid.link/20250629-spi-increase-number-of-cs-v2-1-85a0a09bab32@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-29mtd: nand: qpic_common: prevent out of bounds access of BAM arraysGabor Juhos
The common QPIC code does not do any boundary checking when it handles the command elements and scatter gater list arrays of a BAM transaction, thus it allows to access out of bounds elements in those. Although it is the responsibility of the given driver to allocate enough space for all possible BAM transaction variations, however there can be mistakes in the driver code which can lead to hidden memory corruption issues which are hard to debug. This kind of problem has been observed during testing the 'spi-qpic-snand' driver. Although the driver has been fixed with a preceding patch, but it still makes sense to reduce the chance of having such errors again later. In order to prevent such errors, change the qcom_alloc_bam_transaction() function to store the number of elements of the arrays in the 'bam_transaction' strucutre during allocation. Also, add sanity checks to the qcom_prep_bam_dma_desc_{cmd,data}() functions to avoid using out of bounds indices for the arrays. Tested-by: Lakshmi Sowjanya D <quic_laksd@quicinc.com> # on SDX75 Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://patch.msgid.link/20250618-qpic-snand-avoid-mem-corruption-v3-2-319c71296cda@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-29spi: spi-qpic-snand: reallocate BAM transactionsGabor Juhos
Using the mtd_nandbiterrs module for testing the driver occasionally results in weird things like below. 1. swiotlb mapping fails with the following message: [ 85.926216] qcom_snand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots) [ 85.932937] qcom_snand 79b0000.spi: failure in mapping desc [ 87.999314] qcom_snand 79b0000.spi: failure to write raw page [ 87.999352] mtd_nandbiterrs: error: write_oob failed (-110) Rebooting the board after this causes a panic due to a NULL pointer dereference. 2. If the swiotlb mapping does not fail, rebooting the board may result in a different panic due to a bad spinlock magic: [ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241 [ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b ... Investigating the issue revealed that these symptoms are results of memory corruption which is caused by out of bounds access within the driver. The driver uses a dynamically allocated structure for BAM transactions, which structure must have enough space for all possible variations of different flash operations initiated by the driver. The required space heavily depends on the actual number of 'codewords' which is calculated from the pagesize of the actual NAND chip. Although the qcom_nandc_alloc() function allocates memory for the BAM transactions during probe, but since the actual number of 'codewords' is not yet know the allocation is done for one 'codeword' only. Because of this, whenever the driver does a flash operation, and the number of the required transactions exceeds the size of the allocated arrays the driver accesses memory out of the allocated range. To avoid this, change the code to free the initially allocated BAM transactions memory, and allocate a new one once the actual number of 'codewords' required for a given NAND chip is known. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Reviewed-by: Md Sadre Alam <quic_mdalam@quicinc.com> Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://patch.msgid.link/20250618-qpic-snand-avoid-mem-corruption-v3-1-319c71296cda@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-29regulator: tps65219: Fix devm_kmalloc size allocationShree Ramamoorthy
In probe(), two arrays of structs are allocated with the devm_kmalloc() function, but the memory size of the allocations were given as the arrays' length (pmic->common_irq_size for the first call and pmic->dev_irq_size for the second devm_kmalloc call). The memory size should have been the total memory needed. This led to a heap overflow when the struct array was used. The issue was first discovered with the PocketBeagle2 and BeaglePlay. The common and device-specific structs are now allocated one at a time within the loop. Fixes: 38c9f98db20a ("regulator: tps65219: Add support for TPS65215 Regulator IRQs") Reported-by: Dhruva Gole <d-gole@ti.com> Closes: https://lore.kernel.org/all/20250619153526.297398-1-d-gole@ti.com/ Tested-by: Robert Nelson <robertcnelson@gmail.com> Acked-by: Andrew Davis <afd@ti.com> Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com> Reviewed-by: Nishanth Menon <nm@ti.com> Link: https://patch.msgid.link/20250620154541.2713036-1-s-ramamoorthy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-29regulator: core: fix NULL dereference on unbind due to stale coupling dataAlessandro Carminati
Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can lead to NULL pointer dereference when regulators are accessed post-unbind. This can happen during runtime PM or other regulator operations that rely on coupling metadata. For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulator_lock_recursive() due to stale coupling state. Ensure n_coupled is set to 0 to prevent access to invalid pointers. Signed-off-by: Alessandro Carminati <acarmina@redhat.com> Link: https://patch.msgid.link/20250626083809.314842-1-acarmina@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-29ASoC: Intel: soc-acpi: arl: Correct order of cs42l43 matchesCharles Keepax
Matches should go from more specific to less specific, correct the ordering of two cs42l43 entries. Fixes: c0524067653d ("ASoC: Intel: soc-acpi: arl: Add match entries for new cs42l43 laptops") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250626141841.77780-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-29MAINTAINERS: update Qualcomm audio codec drivers listSrinivas Kandagatla
Some of the codec drivers like wcd939x are missing in the MAINTAINERS which is resulting in incorrect list from get_maintainers script. Fix this by using wildcard matching on both wcd93* and wsa88* codec and bindings. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20250627160329.442795-1-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-29ASoC: fsl_sai: Force a software reset when starting in consumer modeArun Raghavan
On an imx8mm platform with an external clock provider, when running the receiver (arecord) and triggering an xrun with xrun_injection, we see a channel swap/offset. This happens sometimes when running only the receiver, but occurs reliably if a transmitter (aplay) is also concurrently running. It seems that the SAI loses track of frame sync during the trigger stop -> trigger start cycle that occurs during an xrun. Doing just a FIFO reset in this case does not suffice, and only a software reset seems to get it back on track. This looks like the same h/w bug that is already handled for the producer case, so we now do the reset unconditionally on config disable. Signed-off-by: Arun Raghavan <arun@asymptotic.io> Reported-by: Pieterjan Camerlynck <p.camerlynck@televic.com> Fixes: 3e3f8bd56955 ("ASoC: fsl_sai: fix no frame clk in master mode") Cc: stable@vger.kernel.org Reviewed-by: Fabio Estevam <festevam@gmail.com> Link: https://patch.msgid.link/20250626130858.163825-1-arun@arunraghavan.net Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-29ASoC: Intel: SND_SOC_INTEL_SOF_BOARD_HELPERS select SND_SOC_ACPI_INTEL_MATCHBard Liao
The helpers that are provided by SND_SOC_ACPI_INTEL_MATCH (soc-acpi-intel-ssp-common) are used in SND_SOC_INTEL_SOF_BOARD_HELPERS (sof_board_helpers). SND_SOC_ACPI_INTEL_MATCH is selected by machine drivers. When skl_hda_dsp_generic uses the board helpers, it select SND_SOC_INTEL_SOF_BOARD_HELPERS only but not SND_SOC_ACPI_INTEL_MATCH which initroduce the undefined symbol errors. However, it makes more sense that SND_SOC_INTEL_SOF_BOARD_HELPERS select SND_SOC_ACPI_INTEL_MATCH itself. Fixes: b28b23dea314 ("ASoC: Intel: skl_hda_dsp_generic: use common module for DAI links") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506141543.dN0JJyZC-lkp@intel.com/ Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20250626064420.450334-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-29ASoC: fsl_asrc: use internal measured ratio for non-ideal ratio modeShengjiu Wang
When USRC=0, there is underrun issue for the non-ideal ratio mode; according to the reference mannual, the internal measured ratio can be used with USRC=1 and IDRC=0. Fixes: d0250cf4f2ab ("ASoC: fsl_asrc: Add an option to select internal ratio mode") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://patch.msgid.link/20250625020504.2728161-1-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-29Linux 6.16-rc4v6.16-rc4Linus Torvalds
2025-06-29Merge tag 'staging-6.16-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver fix from Greg KH: "Here is a single staging driver fix for 6.16-rc4. It resolves a build error in the rtl8723bs driver for some versions of clang on arm64 when checking the frame size with -Wframe-larger-than. It has been in linux-next for a while now with no reported issues" * tag 'staging-6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: rtl8723bs: Avoid memset() in aes_cipher() and aes_decipher()
2025-06-29Merge tag 'tty-6.16-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial driver fixes from Greg KH: "Here are five small serial and tty and vt fixes for 6.16-rc4. Included in here are: - kerneldoc fixes for recent vt changes - imx serial driver fix - of_node sysfs fix for a regression - vt missing notification fix - 8250 dt bindings fix All of these have been in linux-next for a while with no reported issues" * tag 'tty-6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: dt-bindings: serial: 8250: Make clocks and clock-frequency exclusive serial: imx: Restore original RXTL for console to fix data loss serial: core: restore of_node information in sysfs vt: fix kernel-doc warnings in ucs_get_fallback() vt: add missing notification when switching back to text mode
2025-06-29Merge tag 'edac_urgent_for_v6.16_rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull EDAC fix from Borislav Petkov: - Consider secondary address mask registers in amd64_edac in order to get the correct total memory size of the system * tag 'edac_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/amd64: Fix size calculation for Non-Power-of-Two DIMMs
2025-06-29Merge tag 'x86_urgent_for_v6.16_rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Make sure DR6 and DR7 are initialized to their architectural values and not accidentally cleared, leading to misconfigurations * tag 'x86_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/traps: Initialize DR7 by writing its architectural reset value x86/traps: Initialize DR6 by writing its architectural reset value
2025-06-29Merge tag 'perf_urgent_for_v6.16_rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fix from Borislav Petkov: - Make sure an AUX perf event is really disabled when it overruns * tag 'perf_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/aux: Fix pending disable flow when the AUX ring buffer overruns
2025-06-29Merge tag 'locking_urgent_for_v6.16_rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fix from Borislav Petkov: - Make sure the new futex phash is not copied during fork in order to avoid a double-free * tag 'locking_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: futex: Initialize futex_phash_new during fork().
2025-06-29ALSA: hda/realtek - Add mute LED support for HP Victus 15-fb2xxxEdip Hazuri
The mute led on this laptop is using ALC245 but requires a quirk to work This patch enables the existing quirk for the device. Tested on my friend's Victus 15-fb2xxx Laptop. The LED behaviour works as intended. Cc: <stable@vger.kernel.org> Signed-off-by: Edip Hazuri <edip@medip.dev> Link: https://patch.msgid.link/20250627203415.56785-2-edip@medip.dev Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-06-29ALSA: hda: Add missing NVIDIA HDA codec IDsDaniel Dadap
Add codec IDs for several NVIDIA products with HDA controllers to the snd_hda_id_hdmi[] patch table. Signed-off-by: Daniel Dadap <ddadap@nvidia.com> Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/aF24rqwMKFWoHu12@ddadap-lakeline.nvidia.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-06-29drm/bridge: samsung-dsim: Don't use %pK through printkThomas Weißschuh
In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2025-06-29drm/exynos: fimd: Guard display clock control with runtime PM callsMarek Szyprowski
Commit c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable") changed the call sequence to the CRTC enable/disable and bridge pre_enable/post_disable methods, so those bridge methods are now called when CRTC is not yet enabled. This causes a lockup observed on Samsung Peach-Pit/Pi Chromebooks. The source of this lockup is a call to fimd_dp_clock_enable() function, when FIMD device is not yet runtime resumed. It worked before the mentioned commit only because the CRTC implemented by the FIMD driver was always enabled what guaranteed the FIMD device to be runtime resumed. This patch adds runtime PM guards to the fimd_dp_clock_enable() function to enable its proper operation also when the CRTC implemented by FIMD is not yet enabled. Fixes: 196e059a8a6a ("drm/exynos: convert clock_enable crtc callback to pipeline clock") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2025-06-29drm/exynos: exynos7_drm_decon: add vblank check in IRQ handlingKaustabh Chakraborty
If there's support for another console device (such as a TTY serial), the kernel occasionally panics during boot. The panic message and a relevant snippet of the call stack is as follows: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000 Call trace: drm_crtc_handle_vblank+0x10/0x30 (P) decon_irq_handler+0x88/0xb4 [...] Otherwise, the panics don't happen. This indicates that it's some sort of race condition. Add a check to validate if the drm device can handle vblanks before calling drm_crtc_handle_vblank() to avoid this. Cc: stable@vger.kernel.org Fixes: 96976c3d9aff ("drm/exynos: Add DECON driver") Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2025-06-29drm/exynos: Don't use %pK through printkThomas Weißschuh
In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2025-06-29bcachefs: fix btree_trans_peek_prev_journal()Kent Overstreet
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-28Merge tag 'i2c-for-6.16-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: - imx: fix SMBus protocol compliance during block read - omap: fix error handling path in probe - robotfuzz, tiny-usb: prevent zero-length reads - x86, designware, amdisp: fix build error when modules are disabled (agreed to go in via i2c) - scx200_acb: fix build error because of missing HAS_IOPORT * tag 'i2c-for-6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: scx200_acb: depends on HAS_IOPORT i2c: omap: Fix an error handling path in omap_i2c_probe() platform/x86: Use i2c adapter name to fix build errors i2c: amd-isp: Initialize unique adapter name i2c: designware: Initialize adapter name only when not set i2c: tiny-usb: disable zero-length read messages i2c: robotfuzz-osif: disable zero-length read messages i2c: imx: fix emulated smbus block read
2025-06-28Merge tag 'trace-v6.16-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fix from Steven Rostedt: - Fix possible UAF on error path in filter_free_subsystem_filters() When freeing a subsystem filter, the filter for the subsystem is passed in to be freed and all the events within the subsystem will have their filter freed too. In order to free without waiting for RCU synchronization, list items are allocated to hold what is going to be freed to free it via a call_rcu(). If the allocation of these items fails, it will call the synchronization directly and free after that (causing a bit of delay for the user). The subsystem filter is first added to this list and then the filters for all the events under the subsystem. The bug is if one of the allocations of the list items for the event filters fail to allocate, it jumps to the "free_now" label which will free the subsystem filter, then all the items on the allocated list, and then the event filters that were not added to the list yet. But because the subsystem filter was added first, it gets freed twice. The solution is to add the subsystem filter after the events, and then if any of the allocations fail it will not try to free any of them twice * tag 'trace-v6.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: Fix filter logic error
2025-06-28Merge tag 'loongarch-fixes-6.16-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch fixes from Huacai Chen: - replace __ASSEMBLY__ with __ASSEMBLER__ in headers like others - fix build warnings about export.h - reserve the EFI memory map region for kdump - handle __init vs inline mismatches - fix some KVM bugs * tag 'loongarch-fixes-6.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: LoongArch: KVM: Disable updating of "num_cpu" and "feature" LoongArch: KVM: Check validity of "num_cpu" from user space LoongArch: KVM: Check interrupt route from physical CPU LoongArch: KVM: Fix interrupt route update with EIOINTC LoongArch: KVM: Add address alignment check for IOCSR emulation LoongArch: KVM: Avoid overflow with array index LoongArch: Handle KCOV __init vs inline mismatches LoongArch: Reserve the EFI memory map region LoongArch: Fix build warnings about export.h LoongArch: Replace __ASSEMBLY__ with __ASSEMBLER__ in headers
2025-06-28s390/pci: Allow automatic recovery with minimal driver supportNiklas Schnelle
According to Documentation/PCI/pci-error-recovery.rst only the error_detected() callback in the err_handler struct is mandatory for a driver to support error recovery. So far s390's error recovery chose a stricter approach also requiring slot_reset() and resume(). Relax this requirement and only require error_detected(). If a callback is not implemented EEH and AER treat this as PCI_ERS_RESULT_NONE. This return value is otherwise used by drivers abstaining from their vote on how to proceed with recovery and currently also not supported by s390's recovery code. So to support missing callbacks in-line with other implementors of the recovery flow, also handle PCI_ERS_RESULT_NONE. Since s390 only does per PCI function recovery and does not do voting, treat PCI_ERS_RESULT_NONE optimistically and proceed through recovery unless other failures prevent this. Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Reviewed-by: Julian Ruess <julianr@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-06-28s390/pci: Do not try re-enabling load/store if device is disabledNiklas Schnelle
If a device is disabled unblocking load/store on its own is not useful as a full re-enable of the function is necessary anyway. Note that SCLP Write Event Data Action Qualifier 0 (Reset) leaves the device disabled and triggers this case unless the driver already requests a reset. Cc: stable@vger.kernel.org Fixes: 4cdf2f4e24ff ("s390/pci: implement minimal PCI error recovery") Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-06-28s390/pci: Fix stale function handles in error handlingNiklas Schnelle
The error event information for PCI error events contains a function handle for the respective function. This handle is generally captured at the time the error event was recorded. Due to delays in processing or cascading issues, it may happen that during firmware recovery multiple events are generated. When processing these events in order Linux may already have recovered an affected function making the event information stale. Fix this by doing an unconditional CLP List PCI function retrieving the current function handle with the zdev->state_lock held and ignoring the event if its function handle is stale. Cc: stable@vger.kernel.org Fixes: 4cdf2f4e24ff ("s390/pci: implement minimal PCI error recovery") Reviewed-by: Julian Ruess <julianr@linux.ibm.com> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com> Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-06-28xhci: dbc: Flush queued requests before stopping dbcMathias Nyman
Flush dbc requests when dbc is stopped and transfer rings are freed. Failure to flush them lead to leaking memory and dbc completing odd requests after resuming from suspend, leading to error messages such as: [ 95.344392] xhci_hcd 0000:00:0d.0: no matched request Cc: stable <stable@kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250627144127.3889714-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-28xhci: dbctty: disable ECHO flag by defaultŁukasz Bartosik
When /dev/ttyDBC0 device is created then by default ECHO flag is set for the terminal device. However if data arrives from a peer before application using /dev/ttyDBC0 applies its set of terminal flags then the arriving data will be echoed which might not be desired behavior. Fixes: 4521f1613940 ("xhci: dbctty: split dbc tty driver registration and unregistration functions.") Cc: stable <stable@kernel.org> Signed-off-by: Łukasz Bartosik <ukaszb@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/stable/20250610111802.18742-1-ukaszb%40chromium.org Link: https://lore.kernel.org/r/20250627144127.3889714-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-28xhci: Disable stream for xHC controller with XHCI_BROKEN_STREAMSHongyu Xie
Disable stream for platform xHC controller with broken stream. Fixes: 14aec589327a6 ("storage: accept some UAS devices if streams are unavailable") Cc: stable <stable@kernel.org> Signed-off-by: Hongyu Xie <xiehongyu1@kylinos.cn> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250627144127.3889714-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-28usb: xhci: quirk for data loss in ISOC transfersRaju Rangoju
During the High-Speed Isochronous Audio transfers, xHCI controller on certain AMD platforms experiences momentary data loss. This results in Missed Service Errors (MSE) being generated by the xHCI. The root cause of the MSE is attributed to the ISOC OUT endpoint being omitted from scheduling. This can happen when an IN endpoint with a 64ms service interval either is pre-scheduled prior to the ISOC OUT endpoint or the interval of the ISOC OUT endpoint is shorter than that of the IN endpoint. Consequently, the OUT service is neglected when an IN endpoint with a service interval exceeding 32ms is scheduled concurrently (every 64ms in this scenario). This issue is particularly seen on certain older AMD platforms. To mitigate this problem, it is recommended to adjust the service interval of the IN endpoint to not exceed 32ms (interval 8). This adjustment ensures that the OUT endpoint will not be bypassed, even if a smaller interval value is utilized. Cc: stable <stable@kernel.org> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250627144127.3889714-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-28usb: dwc3: gadget: Fix TRB reclaim logic for short transfers and ZLPsSCHNEIDER Johannes
Commit 96c7bf8f6b3e ("usb: dwc3: gadget: Cleanup SG handling") updated the TRB reclaim path to use the TRB CHN (Chain) bit to determine whether a TRB was part of a chain. However, this inadvertently changed the behavior of reclaiming the final TRB in some scatter-gather or short transfer cases. In particular, if the final TRB did not have the CHN bit set, the cleanup path could incorrectly skip clearing the HWO (Hardware Own) bit, leaving stale TRBs in the ring. This resulted in broken data transfer completions in userspace, notably for MTP over FunctionFS. Fix this by unconditionally clearing the HWO bit during TRB reclaim, regardless of the CHN bit state. This restores correct behavior especially for transfers that require ZLPs or end on non-CHN TRBs. Fixes: 61440628a4ff ("usb: dwc3: gadget: Cleanup SG handling") Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/AM8PR06MB7521A29A8863C838B54987B6BC7BA@AM8PR06MB7521.eurprd06.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.46.0) at 2025-07-24 16:25:07 +0000