Hoi,
This patch series fixes a subtle regression introduced in the recent
scatter-gather cleanup for the DWC3 USB gadget driver, and follows up
with two clean-up patches to simplify and clarify related logic.
Background:
Commit 61440628a4ff ("usb: dwc3: gadget: Cleanup SG handling") removed
some redundant state tracking in the DWC3 gadget driver, including how
scatter-gather TRBs are reclaimed after use. However, the reclaim logic
began relying on the TRB CHN (chain) bit to determine whether TRBs
belonged to a chain — which led to missed TRB reclamation in some
cases.
This broke userspace-facing protocols like MTP (Media Transfer Protocol)
when used via FunctionFS, causing incomplete transfers due to skipped
zero-length packets (ZLPs) or improperly reclaimed short TRBs.
The "offending" chunk from 61440628a4ff:
80 ret = dwc3_gadget_ep_reclaim_completed_trb(dep, req,
81 - trb, event, status, true);
82 + trb, event, status,
83 + !!(trb->ctrl & DWC3_TRB_CTRL_CHN));
Patch 1 fixes the issue by ensuring the HWO bit is always cleared
on reclaimed TRBs, regardless of the CHN bit.
Patches 2 and 3 follow up with simplifications:
- Patch 2 removes the now-redundant `chain` argument to the reclaim function
- Patch 3 simplifies the logic in `dwc3_needs_extra_trb()` to make the conditions easier to read and maintain
All three patches have been tested on a imx8mp based hardware, with
userspace MTP (viveris/uMTP-Responder) over FunctionFS and resolve the
regression while preserving the recent cleanup work.
Signed-off-by: Johannes Schneider <johannes.schneider(a)leica-geosystems.com>
---
Changes in v2:
- dropped Patch 3, as it did change the logic
- CC to stable
- Link to v1: https://lore.kernel.org/r/20250621-dwc3-fix-gadget-mtp-v1-0-a45e6def71bb@le…
---
Johannes Schneider (2):
usb: dwc3: gadget: Fix TRB reclaim logic for short transfers and ZLPs
usb: dwc3: gadget: Simplify TRB reclaim logic by removing redundant 'chain' argument
drivers/usb/dwc3/gadget.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
---
base-commit: d0c22de9995b624f563bc5004d44ac2655712a56
change-id: 20250621-dwc3-fix-gadget-mtp-3c09a6ab84c6
Best regards,
--
Johannes Schneider <johannes.schneider(a)leica-geosystems.com>
This reverts commit ac64f0e893ff370c4d3426c83c1bd0acae75bcf4 which is
upstream commit be4ae8c19492cd6d5de61ccb34ffb3f5ede5eec8.
This commit is causing a suspend regression on Tegra186 Jetson TX2 with
Linux v6.12.y kernels. This is not seen with Linux v6.15 that includes
this change but indicates that there are there changes missing.
Therefore, revert this change.
Fixes: ac64f0e893ff ("cpufreq: tegra186: Share policy per cluster")
Link: https://lore.kernel.org/linux-tegra/bf1dabf7-0337-40e9-8b8e-4e93a0ffd4cc@nv…
Signed-off-by: Jon Hunter <jonathanh(a)nvidia.com>
---
drivers/cpufreq/tegra186-cpufreq.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/cpufreq/tegra186-cpufreq.c b/drivers/cpufreq/tegra186-cpufreq.c
index 4e5b6f9a56d1..7b8fcfa55038 100644
--- a/drivers/cpufreq/tegra186-cpufreq.c
+++ b/drivers/cpufreq/tegra186-cpufreq.c
@@ -73,18 +73,11 @@ static int tegra186_cpufreq_init(struct cpufreq_policy *policy)
{
struct tegra186_cpufreq_data *data = cpufreq_get_driver_data();
unsigned int cluster = data->cpus[policy->cpu].bpmp_cluster_id;
- u32 cpu;
policy->freq_table = data->clusters[cluster].table;
policy->cpuinfo.transition_latency = 300 * 1000;
policy->driver_data = NULL;
- /* set same policy for all cpus in a cluster */
- for (cpu = 0; cpu < ARRAY_SIZE(tegra186_cpus); cpu++) {
- if (data->cpus[cpu].bpmp_cluster_id == cluster)
- cpumask_set_cpu(cpu, policy->cpus);
- }
-
return 0;
}
--
2.43.0
A poorly implemented DisplayPort Alt Mode port partner can indicate
that its pin assignment capabilities are greater than the maximum
value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show
will cause a BRK exception due to an out of bounds array access.
Prevent for loop in pin_assignment_show from accessing
invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX
value in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loop
condition.
Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode")
Cc: stable(a)vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera(a)google.com>
Reviewed-by: Badhri Jagan Sridharan <badhri(a)google.com>
---
drivers/usb/typec/altmodes/displayport.c | 2 +-
include/linux/usb/typec_dp.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c
index b09b58d7311d..773786129dfb 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -677,7 +677,7 @@ static ssize_t pin_assignment_show(struct device *dev,
assignments = get_current_pin_assignments(dp);
- for (i = 0; assignments; assignments >>= 1, i++) {
+ for (i = 0; assignments && i < DP_PIN_ASSIGN_MAX; assignments >>= 1, i++) {
if (assignments & 1) {
if (i == cur)
len += sprintf(buf + len, "[%s] ",
diff --git a/include/linux/usb/typec_dp.h b/include/linux/usb/typec_dp.h
index f2da264d9c14..acb0ad03bdac 100644
--- a/include/linux/usb/typec_dp.h
+++ b/include/linux/usb/typec_dp.h
@@ -57,6 +57,7 @@ enum {
DP_PIN_ASSIGN_D,
DP_PIN_ASSIGN_E,
DP_PIN_ASSIGN_F, /* Not supported after v1.0b */
+ DP_PIN_ASSIGN_MAX,
};
/* DisplayPort alt mode specific commands */
base-commit: e04c78d86a9699d136910cfc0bdcf01087e3267e
--
2.50.0.rc2.701.gf1e915cc24-goog
For some odd reason 5.10 kernel series doesn't compile with a newer
toolchain since 2025-02-09:
2025-02-09T17:32:07.7991299Z GEN .version
2025-02-09T17:32:07.8270062Z CHK include/generated/compile.h
2025-02-09T17:32:07.8540777Z LD vmlinux.o
2025-02-09T17:32:11.7210899Z MODPOST vmlinux.symvers
2025-02-09T17:32:12.0869599Z MODINFO modules.builtin.modinfo
2025-02-09T17:32:12.1403022Z GEN modules.builtin
2025-02-09T17:32:12.1475659Z LD .tmp_vmlinux.btf
2025-02-09T17:32:19.6117204Z BTF .btf.vmlinux.bin.o
2025-02-09T17:32:31.2916650Z LD .tmp_vmlinux.kallsyms1
2025-02-09T17:32:34.8731104Z KSYMS .tmp_vmlinux.kallsyms1.S
2025-02-09T17:32:35.4910608Z AS .tmp_vmlinux.kallsyms1.o
2025-02-09T17:32:35.9662538Z LD .tmp_vmlinux.kallsyms2
2025-02-09T17:32:39.2595984Z KSYMS .tmp_vmlinux.kallsyms2.S
2025-02-09T17:32:39.8802028Z AS .tmp_vmlinux.kallsyms2.o
2025-02-09T17:32:40.3659440Z LD vmlinux
2025-02-09T17:32:48.0031558Z BTFIDS vmlinux
2025-02-09T17:32:48.0143553Z FAILED unresolved symbol filp_close
2025-02-09T17:32:48.5019928Z make: *** [Makefile:1207: vmlinux] Error 255
2025-02-09T17:32:48.5061241Z ==> ERROR: A failure occurred in build().
5.10.234 built fine couple of days ago with the older one. There were
slight changes made. 5.4 and 5.15 still compile.
Wonder what might be missing here ...
--
Best, Philip
From: Takashi Iwai <tiwai(a)suse.de>
[ Upstream commit 4c267ae2ef349639b4d9ebf00dd28586a82fdbe6 ]
When the DMA mode is changed on the (still real!) SB AWE32 after
playing a stream and closing, the previous DMA setup was still
silently kept, and it can confuse the hardware, resulting in the
unexpected noises. As a workaround, enforce the disablement of DMA
setups when the DMA setup is changed by the kcontrol.
https://bugzilla.kernel.org/show_bug.cgi?id=218185
Link: https://patch.msgid.link/20250610064322.26787-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
Based on my analysis of the commit message and code changes, here is my
assessment:
**YES** - This commit should be backported to stable kernel trees.
## Extensive Explanation:
### 1. **Bug Fix Nature**
This commit fixes a real bug that causes "unexpected noises" on SB AWE32
hardware when DMA mode is changed after playing a stream. The fix
addresses a situation where "the previous DMA setup was still silently
kept, and it can confuse the hardware."
### 2. **Code Change Analysis**
The fix is minimal and surgical:
```c
if (change) {
snd_dma_disable(chip->dma8);
snd_dma_disable(chip->dma16);
}
```
This adds only 4 lines that disable both DMA channels when the DMA mode
control changes. The fix is:
- **Small and contained**: Only affects the `snd_sb16_dma_control_put()`
function
- **Low risk**: Simply ensures DMA channels are disabled during mode
switches
- **Clear purpose**: Prevents hardware confusion from stale DMA
configurations
### 3. **Hardware Bug Context**
The kernel repository analysis reveals this is addressing a known class
of hardware issues with SB16 cards:
- The driver documents hardware bugs with DMA mode switching (lines
14-18 in sb16_main.c)
- The hardware has separate 8-bit and 16-bit DMA channels that cannot
mix
- Certain chip revisions have bugs where DMA transfers can block when
switching modes
### 4. **Safety and Side Effects**
The change has minimal side effects:
- Only executes when user changes the DMA mode control
- The driver already checks for active playback/capture before allowing
changes (`if (chip->mode & (SB_MODE_PLAYBACK | SB_MODE_CAPTURE))
return -EBUSY;`)
- `snd_dma_disable()` is a standard ISA DMA function that safely
disables DMA transfers
- The prepare functions already disable/enable DMAs during normal
operation
### 5. **Stable Tree Criteria**
This meets stable tree criteria:
- **Fixes a real bug**: Users experience actual audio problems
(unexpected noises)
- **No new features**: Pure bug fix, no feature additions
- **Minimal change**: 4 lines of straightforward code
- **Low regression risk**: Only affects legacy ISA hardware (SB16/AWE32)
- **Clear bug report**: References kernel bugzilla #218185
### 6. **Legacy Hardware Consideration**
While SB16 is legacy hardware, it's still used:
- The bug report is recent (bugzilla #218185)
- The commit message states this affects "still real!" hardware
- Linux maintains support for legacy hardware in stable trees
- The fix prevents audio corruption which significantly impacts user
experience
The commit follows the pattern of similar audio driver fixes that were
backported (like commit #1 in the examples which fixed DMA
synchronization issues). It's a targeted fix for a specific hardware
problem with no architectural changes.
sound/isa/sb/sb16_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/sound/isa/sb/sb16_main.c b/sound/isa/sb/sb16_main.c
index 679f9f48370ff..b69bc83c103c3 100644
--- a/sound/isa/sb/sb16_main.c
+++ b/sound/isa/sb/sb16_main.c
@@ -722,6 +722,10 @@ static int snd_sb16_dma_control_put(struct snd_kcontrol *kcontrol, struct snd_ct
change = nval != oval;
snd_sb16_set_dma_mode(chip, nval);
spin_unlock_irqrestore(&chip->reg_lock, flags);
+ if (change) {
+ snd_dma_disable(chip->dma8);
+ snd_dma_disable(chip->dma16);
+ }
return change;
}
--
2.39.5