[PATCH AUTOSEL 6.18-6.12] spi: cadence-quadspi: Prevent lost complete() call during indirect read

[PATCH AUTOSEL 6.18-6.12] spi: cadence-quadspi: Prevent lost complete() call during indirect read

[Sasha Levin]

From: Mateusz Litwin <mateusz.litwin@nokia.com>

[ Upstream commit d67396c9d697041b385d70ff2fd59cb07ae167e8 ]

A race condition exists between the read loop and IRQ `complete()` call.
An interrupt could call the complete() between the inner loop and
reinit_completion(), potentially losing the completion event and causing
an unnecessary timeout. Moving reinit_completion() before the loop
prevents this. A premature signal will only result in a spurious wakeup
and another wait cycle, which is preferable to waiting for a timeout.

Signed-off-by: Mateusz Litwin <mateusz.litwin@nokia.com>
Link: https://patch.msgid.link/20251218-cqspi_indirect_read_improve-v2-1-396079972f2a@nokia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

### Summary

**Pros for backporting:**
1. ✅ Fixes a genuine race condition causing timeouts
2. ✅ Small, surgical fix (< 10 lines changed)
3. ✅ Logic is obviously correct and well-explained
4. ✅ Low risk - worst case is benign spurious wakeup
5. ✅ Reviewed by subsystem maintainer (Mark Brown)
6. ✅ No dependencies on other commits
7. ✅ Driver has been in the kernel since 2020, exists in all active
   stable trees
8. ✅ From a reputable source (Nokia) dealing with real hardware

**Cons:**
- None significant. The absence of explicit Fixes:/Cc: stable tags is
  expected for commits under manual review.

### Risk vs Benefit

- **Risk**: Very low - the change is simple, localized, and
  mathematically correct
- **Benefit**: Prevents user-visible timeouts during SPI read operations
  on affected hardware

This commit is an excellent candidate for stable backporting. It fixes a
real race condition bug with a small, obvious, and low-risk change. The
fix has been reviewed by the SPI maintainer and addresses real hardware
issues without introducing new features or significant complexity.

**YES**

 drivers/spi/spi-cadence-quadspi.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index af6d050da1c8..695dbf7142d1 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -769,6 +769,7 @@ static int cqspi_indirect_read_execute(struct cqspi_flash_pdata *f_pdata,
 	readl(reg_base + CQSPI_REG_INDIRECTRD); /* Flush posted write. */
 
 	while (remaining > 0) {
+		ret = 0;
 		if (use_irq &&
 		    !wait_for_completion_timeout(&cqspi->transfer_complete,
 						 msecs_to_jiffies(CQSPI_READ_TIMEOUT_MS)))
@@ -781,6 +782,14 @@ static int cqspi_indirect_read_execute(struct cqspi_flash_pdata *f_pdata,
 		if (cqspi->slow_sram)
 			writel(0x0, reg_base + CQSPI_REG_IRQMASK);
 
+		/*
+		 * Prevent lost interrupt and race condition by reinitializing early.
+		 * A spurious wakeup and another wait cycle can occur here,
+		 * which is preferable to waiting until timeout if interrupt is lost.
+		 */
+		if (use_irq)
+			reinit_completion(&cqspi->transfer_complete);
+
 		bytes_to_read = cqspi_get_rd_sram_level(cqspi);
 
 		if (ret && bytes_to_read == 0) {
@@ -813,7 +822,6 @@ static int cqspi_indirect_read_execute(struct cqspi_flash_pdata *f_pdata,
 		}
 
 		if (use_irq && remaining > 0) {
-			reinit_completion(&cqspi->transfer_complete);
 			if (cqspi->slow_sram)
 				writel(CQSPI_REG_IRQ_WATERMARK, reg_base + CQSPI_REG_IRQMASK);
 		}
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.6] ALSA: usb-audio: Update for native DSD support quirks

[Sasha Levin]

From: Jussi Laako <jussi@sonarnerd.net>

[ Upstream commit da3a7efff64ec0d63af4499eea3a46a2e13b5797 ]

Maintenance patch for native DSD support.

Add set of missing device and vendor quirks; TEAC, Esoteric, Luxman and
Musical Fidelity.

Signed-off-by: Jussi Laako <jussi@sonarnerd.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20251211152224.1780782-1-jussi@sonarnerd.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: ALSA: usb-audio: Update for native DSD support
quirks

### 1. COMMIT MESSAGE ANALYSIS

- **Subject:** "ALSA: usb-audio: Update for native DSD support quirks"
- **Description:** "Maintenance patch" adding "missing device and vendor
  quirks" for TEAC, Esoteric, Luxman, and Musical Fidelity audio devices
- No crash/bug keywords, but no Cc: stable or Fixes: tag is expected for
  commits under review
- Proper sign-offs from author and maintainer (Takashi Iwai, the ALSA
  maintainer)

### 2. CODE CHANGE ANALYSIS

The changes are purely **data table additions** to `sound/usb/quirks.c`:

**Device-specific entries (3):**
1. `0x0644:0x807d` - TEAC UD-507 (DSD DAC + timing quirks)
2. `0x0644:0x806c` - Esoteric XD (DSD DAC + timing quirks)
3. `0x3255:0x0000` - Luxman D-10X (DSD DAC + timing quirk)

**Vendor-wide entry (1):**
4. `0x2772` - Musical Fidelity devices (DSD_RAW quirk)

**Quirk flags used:**
- `QUIRK_FLAG_ITF_USB_DSD_DAC` - Device supports native DSD playback
- `QUIRK_FLAG_CTL_MSG_DELAY` / `QUIRK_FLAG_IFACE_DELAY` - Timing
  workarounds for device communication issues
- `QUIRK_FLAG_DSD_RAW` - Raw DSD mode support

### 3. CLASSIFICATION

This is a **device ID and quirk addition** - explicitly listed as an
allowed exception in stable kernel rules:

> "NEW DEVICE IDs (Very Common): Adding PCI IDs, USB IDs, ACPI IDs, etc.
to existing drivers"
> "QUIRKS and WORKAROUNDS: Hardware-specific quirks for broken/buggy
devices"

The entries follow the exact same pattern as dozens of existing entries
in the file.

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** ~8 lines added (4 entries)
- **Files changed:** 1 file
- **Complexity:** Trivial - pure data table additions
- **Risk:** Extremely low
  - Only affects devices matching specific USB vendor:product IDs
  - No code logic changes whatsoever
  - Cannot affect any other devices
  - Uses pre-existing, well-tested quirk infrastructure

### 5. USER IMPACT

**Benefit:** Owners of these specific high-end audio DACs get:
- Working native DSD playback
- Proper device communication (timing quirks prevent USB control message
  issues)

**Without fix:** These DACs may experience:
- DSD format not working
- Audio glitches or communication failures due to missing timing delays

**Scope:** Narrow (specific device owners only), but critical for those
users.

### 6. STABILITY INDICATORS

- Signed off by Takashi Iwai (ALSA maintainer) - trusted subsystem
  expert
- Follows identical pattern to existing entries
- Zero new code paths introduced

### 7. DEPENDENCY CHECK

- No dependencies on other commits
- All quirk flags (`ITF_USB_DSD_DAC`, `CTL_MSG_DELAY`, `IFACE_DELAY`,
  `DSD_RAW`) already exist in stable kernels
- The quirk_flags_table infrastructure has existed for many kernel
  versions

### DECISION RATIONALE

**This is a textbook stable backport candidate under the device ID/quirk
exception:**

1. **Meets stable criteria for exceptions:** Pure USB device ID and
   quirk additions to existing driver infrastructure
2. **Obviously correct:** Follows exact pattern of adjacent entries in
   the file
3. **Fixes real issue:** Enables hardware that users own to function
   properly
4. **Small and contained:** 8 lines of data-only changes in 1 file
5. **No new features:** DSD support already exists; this just identifies
   which devices can use it
6. **Zero regression risk:** Only activates for specific USB IDs; cannot
   affect other devices

The timing quirks (`CTL_MSG_DELAY`, `IFACE_DELAY`) are particularly
important as they fix actual device communication issues, not just
feature enablement.

**YES**

 sound/usb/quirks.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 61bd61ffb1b2..94a8fdc9c6d3 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2230,6 +2230,12 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 	DEVICE_FLG(0x0644, 0x806b, /* TEAC UD-701 */
 		   QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY |
 		   QUIRK_FLAG_IFACE_DELAY),
+	DEVICE_FLG(0x0644, 0x807d, /* TEAC UD-507 */
+		   QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY |
+		   QUIRK_FLAG_IFACE_DELAY),
+	DEVICE_FLG(0x0644, 0x806c, /* Esoteric XD */
+		   QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY |
+		   QUIRK_FLAG_IFACE_DELAY),
 	DEVICE_FLG(0x06f8, 0xb000, /* Hercules DJ Console (Windows Edition) */
 		   QUIRK_FLAG_IGNORE_CTL_ERROR),
 	DEVICE_FLG(0x06f8, 0xd002, /* Hercules DJ Console (Macintosh Edition) */
@@ -2388,6 +2394,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_CTL_MSG_DELAY_1M),
 	DEVICE_FLG(0x30be, 0x0101, /* Schiit Hel */
 		   QUIRK_FLAG_IGNORE_CTL_ERROR),
+	DEVICE_FLG(0x3255, 0x0000, /* Luxman D-10X */
+		   QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY),
 	DEVICE_FLG(0x339b, 0x3a07, /* Synaptics HONOR USB-C HEADSET */
 		   QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE),
 	DEVICE_FLG(0x413c, 0xa506, /* Dell AE515 sound bar */
@@ -2431,6 +2439,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_DSD_RAW),
 	VENDOR_FLG(0x2622, /* IAG Limited devices */
 		   QUIRK_FLAG_DSD_RAW),
+	VENDOR_FLG(0x2772, /* Musical Fidelity devices */
+		   QUIRK_FLAG_DSD_RAW),
 	VENDOR_FLG(0x278b, /* Rotel? */
 		   QUIRK_FLAG_DSD_RAW),
 	VENDOR_FLG(0x292b, /* Gustard/Ess based devices */
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.1] ASoC: amd: yc: Add quirk for Honor MagicBook X16 2025

[Sasha Levin]

From: Andrew Elantsev <elantsew.andrew@gmail.com>

[ Upstream commit e2cb8ef0372665854fca6fa7b30b20dd35acffeb ]

Add a DMI quirk for the Honor MagicBook X16 2025 laptop
fixing the issue where the internal microphone was
not detected.

Signed-off-by: Andrew Elantsev <elantsew.andrew@gmail.com>
Link: https://patch.msgid.link/20251210203800.142822-1-elantsew.andrew@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Looking at this commit, I'll analyze it systematically to determine if
it's appropriate for stable backporting.

## 1. COMMIT MESSAGE ANALYSIS

- **Subject:** ASoC: amd: yc: Add quirk for Honor MagicBook X16 2025
- **Problem:** Internal microphone not detected on this laptop model
- **Solution:** Add a DMI quirk entry to enable proper audio detection
- Has proper sign-offs from author and Mark Brown (ASoC maintainer)

## 2. CODE CHANGE ANALYSIS

The change is extremely simple - adding one new entry to the
`yc_acp_quirk_table[]` DMI system identification table:

```c
{
    .driver_data = &acp6x_card,
    .matches = {
        DMI_MATCH(DMI_BOARD_VENDOR, "HONOR"),
        DMI_MATCH(DMI_PRODUCT_NAME, "GOH-X"),
    }
},
```

This follows the **exact same pattern** as all other entries in this
table (System76, MSI, etc.). No new code logic is introduced - it just
adds a hardware identifier to an existing quirk mechanism.

## 3. CLASSIFICATION

This is a **hardware quirk/workaround** - one of the explicitly allowed
exception categories for stable trees:
- Adds DMI identification for a specific laptop model
- Uses existing driver infrastructure (`acp6x_card`)
- Enables hardware that would otherwise not function

This is NOT:
- A new feature
- A new driver or API
- Any kind of refactoring or cleanup

## 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** ~7 lines (one struct entry)
- **Files touched:** 1 file
- **Complexity:** Trivial
- **Risk:** Extremely low
  - Only affects Honor MagicBook X16 2025 laptops
  - Cannot possibly break other systems
  - If wrong, only that specific device is affected

## 5. USER IMPACT

- **Affected users:** Honor MagicBook X16 2025 laptop owners
- **Bug severity:** Medium-high - internal microphone completely non-
  functional
- **Real-world impact:** Yes - this is a fix for actual shipping
  hardware where a core feature (microphone) doesn't work

Without this quirk, users cannot use video conferencing, voice
recording, or any audio input on this laptop.

## 6. STABILITY INDICATORS

- Maintainer signed off (Mark Brown, ASoC maintainer)
- Follows established pattern used by dozens of other entries in the
  same file
- The AMD YC audio driver has been stable for years

## 7. DEPENDENCY CHECK

- No dependencies on other commits
- Uses existing `acp6x_card` structure that already exists in stable
- The acp6x-mach.c driver has been in the kernel since 5.x series

## CONCLUSION

This commit is a textbook example of what **should** be backported to
stable:

1. **Obviously correct:** Simple table entry following existing pattern
2. **Fixes a real bug:** Internal microphone doesn't work without it
3. **Small and contained:** 7 lines, single file, no logic changes
4. **No new features:** Just enables existing driver for new hardware
5. **Zero risk to other systems:** Only affects one specific laptop
   model
6. **Falls under quirk exception:** Hardware quirks are explicitly
   allowed in stable

DMI quirk additions like this are routinely backported to stable trees
because they provide significant user benefit (making hardware work)
with essentially zero risk to existing functionality.

**YES**

 sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index f210a253da9f..bf4d9d336561 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -661,6 +661,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "Bravo 15 C7UCX"),
 		}
 	},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "HONOR"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "GOH-X"),
+		}
+	},
 	{}
 };
 
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] ASoC: fsl_sai: Add missing registers to cache default

[Sasha Levin]

From: Alexander Stein <alexander.stein@ew.tq-group.com>

[ Upstream commit 90ed688792a6b7012b3e8a2f858bc3fe7454d0eb ]

Drivers does cache sync during runtime resume, setting all writable
registers. Not all writable registers are set in cache default, resulting
in the erorr message:
  fsl-sai 30c30000.sai: using zero-initialized flat cache, this may cause
  unexpected behavior

Fix this by adding missing writable register defaults.

Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://patch.msgid.link/20251216102246.676181-1-alexander.stein@ew.tq-group.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis Summary

### 1. What Problem Does This Commit Solve?

This commit fixes a bug where the FSL SAI driver's regmap cache was
incomplete. During runtime resume, the driver performs a cache sync that
writes all writable registers. Two writable registers (`FSL_SAI_TTCTL`
and `FSL_SAI_RTCTL`) were missing from the cache defaults array,
causing:

1. A warning message: `fsl-sai 30c30000.sai: using zero-initialized flat
   cache, this may cause unexpected behavior`
2. Potentially incorrect behavior during suspend/resume cycles

### 2. Root Cause Analysis

The bug was introduced in commit `0b2cbce68986` ("ASoC: fsl_sai: Add new
added registers and new bit definition") from September 2020, which:
- Added `FSL_SAI_TTCTL` and `FSL_SAI_RTCTL` to `fsl_sai_writeable_reg()`
  (lines 1234-1235)
- But **failed** to add them to `fsl_sai_reg_defaults_ofs0[]` and
  `fsl_sai_reg_defaults_ofs8[]`

The current commit completes what should have been done in the original
commit.

### 3. Code Change Assessment

The fix is minimal and surgical:
- Adds `{FSL_SAI_TTCTL, 0}` to `fsl_sai_reg_defaults_ofs0[]` (+1 line)
- Adds `{FSL_SAI_TTCTL, 0}` to `fsl_sai_reg_defaults_ofs8[]` (+1 line)
- Adds `{FSL_SAI_RTCTL, 0}` to `fsl_sai_reg_defaults_ofs8[]` (+1 line)

Total: 3 lines added, all initializing registers to default value 0.

### 4. Stable Criteria Check

| Criteria | Assessment |
|----------|------------|
| Obviously correct | ✅ Yes - completing missing register defaults |
| Fixes real bug | ✅ Yes - fixes warning and potential misbehavior |
| Small scope | ✅ Yes - only 3 lines added to static arrays |
| No new features | ✅ Yes - purely fixes incomplete initialization |
| Tested | ✅ Accepted by subsystem maintainer (Mark Brown) |

### 5. Risk Assessment

**Risk: Very Low**
- No logic changes, only adds entries to static const arrays
- Default values are 0 (standard hardware reset value)
- The registers already existed and were marked writable
- Change is purely additive to existing data structures

### 6. Affected Stable Trees

The bug exists in kernels v5.10+ (when commit 0b2cbce68986 was merged).
Relevant stable trees:
- 5.10.y (LTS)
- 5.15.y (LTS)
- 6.1.y (LTS)
- 6.6.y (LTS)
- 6.11.y and newer

### 7. User Impact

Affects users of NXP/Freescale i.MX processors using SAI audio
interfaces, particularly those using suspend/resume (common on embedded
systems, tablets, etc.).

### Conclusion

This is an excellent stable backport candidate. It's a minimal, low-risk
fix that corrects a longstanding bug in driver initialization. The fix
simply completes the register cache defaults that should have been
included when the registers were made writable in 2020. The warning
message indicates potential undefined behavior, and the fix is as simple
and safe as adding entries to a static array.

**YES**

 sound/soc/fsl/fsl_sai.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 72bfc91e21b9..090354a0f711 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -1075,6 +1075,7 @@ static const struct reg_default fsl_sai_reg_defaults_ofs0[] = {
 	{FSL_SAI_TDR6, 0},
 	{FSL_SAI_TDR7, 0},
 	{FSL_SAI_TMR, 0},
+	{FSL_SAI_TTCTL, 0},
 	{FSL_SAI_RCR1(0), 0},
 	{FSL_SAI_RCR2(0), 0},
 	{FSL_SAI_RCR3(0), 0},
@@ -1098,12 +1099,14 @@ static const struct reg_default fsl_sai_reg_defaults_ofs8[] = {
 	{FSL_SAI_TDR6, 0},
 	{FSL_SAI_TDR7, 0},
 	{FSL_SAI_TMR, 0},
+	{FSL_SAI_TTCTL, 0},
 	{FSL_SAI_RCR1(8), 0},
 	{FSL_SAI_RCR2(8), 0},
 	{FSL_SAI_RCR3(8), 0},
 	{FSL_SAI_RCR4(8), 0},
 	{FSL_SAI_RCR5(8), 0},
 	{FSL_SAI_RMR, 0},
+	{FSL_SAI_RTCTL, 0},
 	{FSL_SAI_MCTL, 0},
 	{FSL_SAI_MDIV, 0},
 };
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] ALSA: hda/realtek: enable woofer speakers on Medion NM14LNL

[Sasha Levin]

From: Kai Vehmanen <kai.vehmanen@linux.intel.com>

[ Upstream commit e64826e5e367ad45539ab245b92f009ee165025c ]

The ALC233 codec on these Medion NM14LNL (SPRCHRGD 14 S2) systems
requires a quirk to enable all speakers.

Tested-by: davplsm <davpal@yahoo.com>
Link: https://github.com/thesofproject/linux/issues/5611
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20251212174658.752641-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of Commit: ALSA: hda/realtek: enable woofer speakers on
Medion NM14LNL

### 1. COMMIT MESSAGE ANALYSIS

- **Subject indicates:** Hardware quirk addition for speaker support
- **Bug indicators:** Links to GitHub issue
  (thesofproject/linux/issues/5611) - a real bug report
- **Testing indicators:** Has `Tested-by:` tag from the user who
  reported the issue
- **Maintainer sign-off:** Signed by Kai Vehmanen (Intel) and Takashi
  Iwai (SUSE) - primary ALSA maintainers

### 2. CODE CHANGE ANALYSIS

The change is a **single line addition**:
```c
SND_PCI_QUIRK(0x1e39, 0xca14, "MEDION NM14LNL",
ALC233_FIXUP_MEDION_MTL_SPK),
```

This adds a PCI subsystem ID quirk entry to the `alc269_fixup_tbl[]`
table:
- Vendor ID: `0x1e39`
- Subsystem ID: `0xca14`
- Applies the existing `ALC233_FIXUP_MEDION_MTL_SPK` fixup

Notably, the same fixup is already used by another device visible in the
diff:
```c
SND_PCI_QUIRK(0x2782, 0x4900, "MEDION E15443",
ALC233_FIXUP_MEDION_MTL_SPK),
```

This proves the fixup code already exists and is working in production.

### 3. CLASSIFICATION

This is a **hardware quirk addition** - one of the explicitly allowed
exception categories for stable backports:
- Not adding new features or APIs
- Not adding new drivers
- Simply enabling existing, tested functionality for a specific hardware
  model

### 4. SCOPE AND RISK ASSESSMENT

| Metric | Value |
|--------|-------|
| Lines added | 1 |
| Lines removed | 0 |
| Files changed | 1 |
| Risk level | **EXTREMELY LOW** |

**Why low risk:**
- Only affects Medion NM14LNL laptops (subsystem ID 0x1e39:0xca14)
- Zero impact on any other hardware
- Uses an already-proven fixup (`ALC233_FIXUP_MEDION_MTL_SPK`)
- Well-understood, static quirk table pattern

### 5. USER IMPACT

- **Affected users:** Owners of Medion NM14LNL (SPRCHRGD 14 S2) laptops
- **Problem without fix:** Woofer speakers don't work
- **Severity:** Moderate-high for affected users (hardware they paid for
  doesn't function)
- **Evidence of real bug:** GitHub issue with user testing confirms this
  is a real problem

### 6. STABILITY INDICATORS

- ✅ `Tested-by:` tag present
- ✅ Maintained by experienced ALSA maintainers
- ✅ Same fixup already in use by another Medion device
- ✅ Follows established quirk addition pattern

### 7. DEPENDENCY CHECK

The only dependency is `ALC233_FIXUP_MEDION_MTL_SPK`, which already
exists in the codebase (used by MEDION E15443). This fixup should be
present in any stable kernel that has reasonably recent Realtek HDA
updates.

---

## Summary

This commit is a **textbook example** of what should be backported to
stable:

1. **Meets stable rules:** Obviously correct, fixes a real bug,
   extremely small scope, no new features
2. **Falls under explicit exception:** Hardware quirks are specifically
   allowed in stable
3. **Risk/benefit ratio:** Zero risk (affects only one laptop model),
   clear benefit (working speakers)
4. **Well-tested:** Has Tested-by tag and uses proven fixup code
5. **Clean application:** Single line addition to a quirk table, will
   apply cleanly

The fix enables non-functional speakers on a specific laptop model by
adding a single quirk table entry that maps the hardware ID to an
existing, proven fixup. This is precisely the type of low-risk, user-
facing hardware fix that stable kernels should receive.

**YES**

 sound/hda/codecs/realtek/alc269.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index a6d494dab5b6..43c80a8ad72e 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7203,6 +7203,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x1d72, 0x1901, "RedmiBook 14", ALC256_FIXUP_ASUS_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1d72, 0x1945, "Redmi G", ALC256_FIXUP_ASUS_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1d72, 0x1947, "RedmiBook Air", ALC255_FIXUP_XIAOMI_HEADSET_MIC),
+	SND_PCI_QUIRK(0x1e39, 0xca14, "MEDION NM14LNL", ALC233_FIXUP_MEDION_MTL_SPK),
 	SND_PCI_QUIRK(0x1ee7, 0x2078, "HONOR BRB-X M1010", ALC2XX_FIXUP_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1f66, 0x0105, "Ayaneo Portable Game Player", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x2014, 0x800a, "Positivo ARN50", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] scsi: sg: Fix occasional bogus elapsed time that exceeds timeout

[Sasha Levin]

From: Michal Rábek <mrabek@redhat.com>

[ Upstream commit 0e1677654259a2f3ccf728de1edde922a3c4ba57 ]

A race condition was found in sg_proc_debug_helper(). It was observed on
a system using an IBM LTO-9 SAS Tape Drive (ULTRIUM-TD9) and monitoring
/proc/scsi/sg/debug every second. A very large elapsed time would
sometimes appear. This is caused by two race conditions.

We reproduced the issue with an IBM ULTRIUM-HH9 tape drive on an x86_64
architecture. A patched kernel was built, and the race condition could
not be observed anymore after the application of this patch. A
reproducer C program utilising the scsi_debug module was also built by
Changhui Zhong and can be viewed here:

https://github.com/MichaelRabek/linux-tests/blob/master/drivers/scsi/sg/sg_race_trigger.c

The first race happens between the reading of hp->duration in
sg_proc_debug_helper() and request completion in sg_rq_end_io().  The
hp->duration member variable may hold either of two types of
information:

 #1 - The start time of the request. This value is present while
      the request is not yet finished.

 #2 - The total execution time of the request (end_time - start_time).

If sg_proc_debug_helper() executes *after* the value of hp->duration was
changed from #1 to #2, but *before* srp->done is set to 1 in
sg_rq_end_io(), a fresh timestamp is taken in the else branch, and the
elapsed time (value type #2) is subtracted from a timestamp, which
cannot yield a valid elapsed time (which is a type #2 value as well).

To fix this issue, the value of hp->duration must change under the
protection of the sfp->rq_list_lock in sg_rq_end_io().  Since
sg_proc_debug_helper() takes this read lock, the change to srp->done and
srp->header.duration will happen atomically from the perspective of
sg_proc_debug_helper() and the race condition is thus eliminated.

The second race condition happens between sg_proc_debug_helper() and
sg_new_write(). Even though hp->duration is set to the current time
stamp in sg_add_request() under the write lock's protection, it gets
overwritten by a call to get_sg_io_hdr(), which calls copy_from_user()
to copy struct sg_io_hdr from userspace into kernel space. hp->duration
is set to the start time again in sg_common_write(). If
sg_proc_debug_helper() is called between these two calls, an arbitrary
value set by userspace (usually zero) is used to compute the elapsed
time.

To fix this issue, hp->duration must be set to the current timestamp
again after get_sg_io_hdr() returns successfully. A small race window
still exists between get_sg_io_hdr() and setting hp->duration, but this
window is only a few instructions wide and does not result in observable
issues in practice, as confirmed by testing.

Additionally, we fix the format specifier from %d to %u for printing
unsigned int values in sg_proc_debug_helper().

Signed-off-by: Michal Rábek <mrabek@redhat.com>
Suggested-by: Tomas Henzl <thenzl@redhat.com>
Tested-by: Changhui Zhong <czhong@redhat.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: John Meneghini <jmeneghi@redhat.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Link: https://patch.msgid.link/20251212160900.64924-1-mrabek@redhat.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of commit: "scsi: sg: Fix occasional bogus elapsed time that
exceeds timeout"

### 1. COMMIT MESSAGE ANALYSIS

The commit clearly describes two race conditions in the SCSI sg driver:
- **Race 1:** Between reading `hp->duration` in `sg_proc_debug_helper()`
  and request completion in `sg_rq_end_io()` - duration gets updated
  before `srp->done` is set, causing incorrect timestamp subtraction
- **Race 2:** Between `sg_proc_debug_helper()` and `sg_new_write()` -
  userspace can set arbitrary values for `hp->duration` via
  `copy_from_user()` before the kernel resets it

The bug was observed on real hardware (IBM LTO-9 SAS Tape Drive).
There's a reproducer available and the fix has been tested.

**Quality indicators:**
- `Tested-by:` tag present
- `Reviewed-by:` from 3 different reviewers
- Link to reproducer code on GitHub
- Detailed technical explanation

### 2. CODE CHANGE ANALYSIS

**Change 1 - `sg_new_write()` (~line 734):**
Adds `hp->duration = jiffies_to_msecs(jiffies);` immediately after
`get_sg_io_hdr()` returns. This fixes race #2 by ensuring userspace-
supplied values are overwritten with the correct timestamp right away.

**Change 2 - `sg_common_write()` (~line 820):**
Removes the `hp->duration = jiffies_to_msecs(jiffies);` line since it's
now set earlier in `sg_new_write()`.

**Change 3 - `sg_rq_end_io()` (~lines 1341-1392):**
Moves the duration calculation **inside** the write lock:
```c
write_lock_irqsave(&sfp->rq_list_lock, iflags);
// ...
srp->done = done;
ms = jiffies_to_msecs(jiffies);
srp->header.duration = (ms > srp->header.duration) ? (ms -
srp->header.duration) : 0;
write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
```
This makes `srp->done` and `srp->header.duration` updates atomic from
`sg_proc_debug_helper()`'s perspective.

**Change 4 - `sg_proc_debug_helper()` (~lines 2550-2570):**
- Uses `READ_ONCE(hp->duration)` for proper memory ordering
- Fixes format specifier `%d` to `%u` for unsigned int values
- Adds local `duration` variable to capture the value atomically

### 3. CLASSIFICATION

- **Type:** Bug fix (race condition)
- **Impact:** Incorrect elapsed time values displayed in
  `/proc/scsi/sg/debug`
- **Not a security issue**, not data corruption, not a crash

### 4. SCOPE AND RISK ASSESSMENT

- **Files touched:** 1 (`drivers/scsi/sg.c`)
- **Lines changed:** Moderate - mostly code movement and reordering
- **Complexity:** Low - uses existing locking mechanisms, no new logic
- **Risk:** LOW - the fix applies proper locking discipline; no
  fundamental behavioral change

### 5. USER IMPACT

- **Affected users:** Enterprise users with SCSI tape drives (backup
  systems), users of sg interface for direct SCSI access
- **Severity:** Medium - incorrect diagnostic information can mislead
  troubleshooting, but not a crash or data loss
- **Reproducibility:** Confirmed reproducible with reproducer tool

### 6. STABILITY INDICATORS

- 3 `Reviewed-by:` tags (Ewan D. Milne, John Meneghini, Tomas Henzl)
- 1 `Tested-by:` tag
- Authors from Red Hat (enterprise relevance)
- Reproducer publicly available

### 7. DEPENDENCY CHECK

- No dependencies on other commits
- Uses `READ_ONCE()` - available in all stable kernels
- `rq_list_lock` and related structures are long-standing
- The sg driver is mature and present in all stable trees

### STABLE KERNEL CRITERIA EVALUATION

| Criterion | Assessment |
|-----------|------------|
| Obviously correct | ✅ Yes - proper locking discipline |
| Fixes real bug | ✅ Yes - documented race condition with reproducer |
| Tested | ✅ Yes - Tested-by tag present |
| Small and contained | ✅ Yes - single file, focused changes |
| No new features | ✅ Yes - only fixes race |
| No new APIs | ✅ Yes |

### RISK VS BENEFIT

**Benefits:**
- Fixes race conditions causing incorrect timing values in /proc
- Enterprise relevance (tape backup systems)
- Well-tested and reviewed

**Risks:**
- Minimal - code movement under existing locks
- No functional changes to I/O path

**Concerns:**
- The bug is diagnostic in nature (incorrect display) rather than
  crash/corruption
- However, the fix is safe and meets all stable criteria

### CONCLUSION

This commit fixes two real race conditions in the SCSI sg driver that
have been observed in production environments with tape drives. The fix
is surgical, well-tested, thoroughly reviewed (3 reviewers), and follows
proper locking discipline. While the bug manifests as incorrect timing
information in /proc rather than a crash, it affects enterprise users
relying on accurate diagnostic information. The fix has low regression
risk and cleanly applies to the long-standing sg driver code.

**YES**

 drivers/scsi/sg.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index b3af9b78fa12..57fba34832ad 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -731,6 +731,8 @@ sg_new_write(Sg_fd *sfp, struct file *file, const char __user *buf,
 		sg_remove_request(sfp, srp);
 		return -EFAULT;
 	}
+	hp->duration = jiffies_to_msecs(jiffies);
+
 	if (hp->interface_id != 'S') {
 		sg_remove_request(sfp, srp);
 		return -ENOSYS;
@@ -815,7 +817,6 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp,
 		return -ENODEV;
 	}
 
-	hp->duration = jiffies_to_msecs(jiffies);
 	if (hp->interface_id != '\0' &&	/* v3 (or later) interface */
 	    (SG_FLAG_Q_AT_TAIL & hp->flags))
 		at_head = 0;
@@ -1338,9 +1339,6 @@ sg_rq_end_io(struct request *rq, blk_status_t status)
 				      "sg_cmd_done: pack_id=%d, res=0x%x\n",
 				      srp->header.pack_id, result));
 	srp->header.resid = resid;
-	ms = jiffies_to_msecs(jiffies);
-	srp->header.duration = (ms > srp->header.duration) ?
-				(ms - srp->header.duration) : 0;
 	if (0 != result) {
 		struct scsi_sense_hdr sshdr;
 
@@ -1389,6 +1387,9 @@ sg_rq_end_io(struct request *rq, blk_status_t status)
 			done = 0;
 	}
 	srp->done = done;
+	ms = jiffies_to_msecs(jiffies);
+	srp->header.duration = (ms > srp->header.duration) ?
+				(ms - srp->header.duration) : 0;
 	write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
 
 	if (likely(done)) {
@@ -2533,6 +2534,7 @@ static void sg_proc_debug_helper(struct seq_file *s, Sg_device * sdp)
 	const sg_io_hdr_t *hp;
 	const char * cp;
 	unsigned int ms;
+	unsigned int duration;
 
 	k = 0;
 	list_for_each_entry(fp, &sdp->sfds, sfd_siblings) {
@@ -2570,13 +2572,17 @@ static void sg_proc_debug_helper(struct seq_file *s, Sg_device * sdp)
 			seq_printf(s, " id=%d blen=%d",
 				   srp->header.pack_id, blen);
 			if (srp->done)
-				seq_printf(s, " dur=%d", hp->duration);
+				seq_printf(s, " dur=%u", hp->duration);
 			else {
 				ms = jiffies_to_msecs(jiffies);
-				seq_printf(s, " t_o/elap=%d/%d",
+				duration = READ_ONCE(hp->duration);
+				if (duration)
+					duration = (ms > duration ?
+						    ms - duration : 0);
+				seq_printf(s, " t_o/elap=%u/%u",
 					(new_interface ? hp->timeout :
 						  jiffies_to_msecs(fp->timeout)),
-					(ms > hp->duration ? ms - hp->duration : 0));
+					duration);
 			}
 			seq_printf(s, "ms sgat=%d op=0x%02x\n", usg,
 				   (int) srp->data.cmd_opcode);
-- 
2.51.0