[PATCH AUTOSEL 6.18-6.17] ALSA: hda/realtek: Add support for ASUS UM3406GA

[PATCH AUTOSEL 6.18-6.17] ALSA: hda/realtek: Add support for ASUS UM3406GA

[Sasha Levin]

From: Stefan Binding <sbinding@opensource.cirrus.com>

[ Upstream commit 826c0b1ed09e5335abcae07292440ce72346e578 ]

Laptops use 2 CS35L41 Amps with HDA, using External boost, with I2C

Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://patch.msgid.link/20251205150614.49590-3-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: ALSA: hda/realtek: Add support for ASUS UM3406GA

### 1. COMMIT MESSAGE ANALYSIS

The commit message is straightforward: it adds support for a specific
ASUS laptop model (UM3406GA) that uses 2 CS35L41 amplifiers connected
via I2C with external boost. The message describes the hardware
configuration, which is standard for such device ID additions.

No Fixes: or Cc: stable tags are present, but as noted, this is expected
for commits requiring manual review.

### 2. CODE CHANGE ANALYSIS

The entire change is a single line addition:
```c
SND_PCI_QUIRK(0x1043, 0x1584, "ASUS UM3406GA ",
ALC287_FIXUP_CS35L41_I2C_2),
```

This adds:
- Vendor ID: 0x1043 (ASUS)
- Device/Subsystem ID: 0x1584 (ASUS UM3406GA)
- Fixup: `ALC287_FIXUP_CS35L41_I2C_2` (an **existing** fixup already
  used by many other ASUS models)

Looking at the surrounding code, multiple other ASUS laptops use the
same fixup:
- ASUS PM3406CKA (0x1454)
- ASUS G513PI/PU/PV (0x14e3)
- ASUS G733PY/PZ/PZV/PYV (0x1503)
- ASUS GV302XA/XJ/XQ/XU/XV/XI (0x1533)
- ASUS UM3402YAR (0x1683)

### 3. CLASSIFICATION

This is a **NEW DEVICE ID** addition - explicitly listed as an exception
that IS appropriate for stable backporting. The driver infrastructure
and fixup code already exist; this merely adds an ID to enable the
existing fix for new hardware.

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed**: 1 line
- **Files touched**: 1 file
- **Complexity**: Zero - table entry addition only
- **Risk**: Extremely low - this cannot affect any other hardware
- **No new code paths**: Uses pre-existing `ALC287_FIXUP_CS35L41_I2C_2`
  fixup

### 5. USER IMPACT

- **Who is affected**: Owners of ASUS UM3406GA laptops
- **Problem without fix**: Audio (specifically the CS35L41 amplifiers)
  won't function properly
- **Severity**: Non-working audio is a significant user-facing issue for
  laptop users

### 6. STABILITY INDICATORS

- Signed-off by Takashi Iwai (ALSA maintainer at SUSE)
- Standard quirk addition pattern used extensively throughout this file
- Follows exact same format as dozens of other ASUS quirk entries

### 7. DEPENDENCY CHECK

- The fixup `ALC287_FIXUP_CS35L41_I2C_2` has been in the kernel for some
  time, supporting multiple other ASUS models
- No other commits are required for this to work
- This should apply cleanly to stable trees that have the CS35L41
  support infrastructure

### CONCLUSION

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

1. **Falls under explicit exception**: Adding device IDs to existing
   drivers is explicitly allowed
2. **Minimal change**: Single line, single table entry
3. **Zero regression risk**: Cannot affect any hardware except the
   targeted laptop
4. **Uses existing infrastructure**: The fixup is already well-tested on
   similar ASUS models
5. **Fixes real user problem**: Enables audio on a production laptop
6. **Obviously correct**: Identical pattern to surrounding entries

The risk-benefit analysis strongly favors backporting: virtually zero
risk with clear user benefit (working audio on a specific laptop model).

**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 b45fcc9a3785e..008bf9d5148e1 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6752,6 +6752,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
 	SND_PCI_QUIRK(0x1043, 0x1533, "ASUS GV302XA/XJ/XQ/XU/XV/XI", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x1043, 0x1573, "ASUS GZ301VV/VQ/VU/VJ/VA/VC/VE/VVC/VQC/VUC/VJC/VEC/VCC", ALC285_FIXUP_ASUS_HEADSET_MIC),
+	SND_PCI_QUIRK(0x1043, 0x1584, "ASUS UM3406GA ", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x1043, 0x1652, "ASUS ROG Zephyrus Do 15 SE", ALC289_FIXUP_ASUS_ZEPHYRUS_DUAL_SPK),
 	SND_PCI_QUIRK(0x1043, 0x1662, "ASUS GV301QH", ALC294_FIXUP_ASUS_DUAL_SPK),
 	SND_PCI_QUIRK(0x1043, 0x1663, "ASUS GU603ZI/ZJ/ZQ/ZU/ZV", ALC285_FIXUP_ASUS_HEADSET_MIC),
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.1] smb/client: fix NT_STATUS_NO_DATA_DETECTED value

[Sasha Levin]

From: ChenXiaoSong <chenxiaosong@kylinos.cn>

[ Upstream commit a1237c203f1757480dc2f3b930608ee00072d3cc ]

This was reported by the KUnit tests in the later patches.

See MS-ERREF 2.3.1 STATUS_NO_DATA_DETECTED. Keep it consistent with the
value in the documentation.

Signed-off-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of Commit: smb/client: fix NT_STATUS_NO_DATA_DETECTED value

### 1. COMMIT MESSAGE ANALYSIS
- Subject clearly states "fix" indicating a bug fix
- References MS-ERREF 2.3.1 (Microsoft's official NTSTATUS
  documentation) as the authoritative source
- Bug was discovered through KUnit tests
- Has Acked-by from Paulo Alcantara (Red Hat SMB maintainer) and Signed-
  off-by from Steve French (primary SMB/CIFS maintainer)

### 2. CODE CHANGE ANALYSIS

The change is a single-line fix in a header file:
```c
-#define NT_STATUS_NO_DATA_DETECTED 0x8000001c
+#define NT_STATUS_NO_DATA_DETECTED 0x80000022
```

**Critical bug identified**: The OLD value `0x8000001c` was
**duplicated** with another constant defined just a few lines above:
```c
#define NT_STATUS_MEDIA_CHANGED    0x8000001c
```

This is clearly a bug - two distinct Windows NT error status codes were
sharing the same numeric value. This would cause:
- Incorrect error code interpretation when servers return
  STATUS_NO_DATA_DETECTED (0x80000022)
- Potential confusion between STATUS_MEDIA_CHANGED and
  STATUS_NO_DATA_DETECTED

The new value `0x80000022` matches the official Microsoft MS-ERREF
specification for STATUS_NO_DATA_DETECTED.

### 3. CLASSIFICATION
- **Bug fix**: Yes - corrects a provably incorrect constant value
- **Feature addition**: No
- **New API**: No
- **Specification compliance fix**: Aligns with official Microsoft
  documentation

### 4. SCOPE AND RISK ASSESSMENT
- **Size**: 1 line changed
- **Files**: 1 header file
- **Risk**: Extremely low - simply correcting a wrong numeric constant
- **Subsystem**: SMB client (commonly used for network file sharing)

This is about as low-risk as a fix can get - it's correcting a single
constant value to match official documentation. The previous value was
demonstrably wrong (duplicate of another constant).

### 5. USER IMPACT
SMB is widely used for file sharing across networks. Having correct
error status codes is important for proper error handling. While the
practical impact depends on how this constant is used, having correct
protocol constants is essential for interoperability.

### 6. STABILITY INDICATORS
- Acked by Red Hat's SMB maintainer
- Signed off by the primary CIFS/SMB maintainer (Steve French)
- KUnit tests caught this issue, indicating testing coverage

### 7. DEPENDENCY CHECK
- No dependencies on other commits
- Standalone fix to a header constant
- SMB client code exists in stable trees

### Summary

**Meets stable criteria:**
- ✅ Obviously correct (matches official MS-ERREF documentation)
- ✅ Fixes a real bug (duplicate constant value)
- ✅ Extremely small and contained (single line change)
- ✅ No new features or APIs
- ✅ Low risk (just correcting a constant value)

**Risk vs Benefit:**
- Risk: Minimal - changing a constant to its documented correct value
- Benefit: Correct SMB error handling, protocol compliance

This is a textbook example of a safe stable backport candidate: an
obviously wrong value is corrected to match official documentation, the
change is tiny, and there's no possibility of regression since the old
value was demonstrably incorrect (it was a duplicate of
NT_STATUS_MEDIA_CHANGED).

**YES**

 fs/smb/client/nterr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/smb/client/nterr.h b/fs/smb/client/nterr.h
index b3516c71cff77..09263c91d07a4 100644
--- a/fs/smb/client/nterr.h
+++ b/fs/smb/client/nterr.h
@@ -41,7 +41,7 @@ extern const struct nt_err_code_struct nt_errs[];
 #define NT_STATUS_MEDIA_CHANGED    0x8000001c
 #define NT_STATUS_END_OF_MEDIA     0x8000001e
 #define NT_STATUS_MEDIA_CHECK      0x80000020
-#define NT_STATUS_NO_DATA_DETECTED 0x8000001c
+#define NT_STATUS_NO_DATA_DETECTED 0x80000022
 #define NT_STATUS_STOPPED_ON_SYMLINK 0x8000002d
 #define NT_STATUS_DEVICE_REQUIRES_CLEANING 0x80000288
 #define NT_STATUS_DEVICE_DOOR_OPEN 0x80000289
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.17] ALSA: hda: intel-dsp-config: Prefer legacy driver as fallback

[Sasha Levin]

From: Takashi Iwai <tiwai@suse.de>

[ Upstream commit 161a0c617ab172bbcda7ce61803addeb2124dbff ]

When config table entries don't match with the device to be probed,
currently we fall back to SND_INTEL_DSP_DRIVER_ANY, which means to
allow any drivers to bind with it.

This was set so with the assumption (or hope) that all controller
drivers should cover the devices generally, but in practice, this
caused a problem as reported recently.  Namely, when a specific
kconfig for SOF isn't set for the modern Intel chips like Alderlake,
a wrong driver (AVS) got probed and failed.  This is because we have
entries like:

 #if IS_ENABLED(CONFIG_SND_SOC_SOF_ALDERLAKE)
 /* Alder Lake / Raptor Lake */
 	{
 		.flags = FLAG_SOF | FLAG_SOF_ONLY_IF_DMIC_OR_SOUNDWIRE,
 		.device = PCI_DEVICE_ID_INTEL_HDA_ADL_S,
 	},
 ....
 #endif

so this entry is effective only when CONFIG_SND_SOC_SOF_ALDERLAKE is
set.  If not set, there is no matching entry, hence it returns
SND_INTEL_DSP_DRIVER_ANY as fallback.  OTOH, if the kconfig is set, it
explicitly falls back to SND_INTEL_DSP_DRIVER_LEGACY when no DMIC or
SoundWire is found -- that was the working scenario.  That being said,
the current setup may be broken for modern Intel chips that are
supposed to work with either SOF or legacy driver when the
corresponding kconfig were missing.

For addressing the problem above, this patch changes the fallback
driver to the legacy driver, i.e. return SND_INTEL_DSP_DRIVER_LEGACY
type as much as possible.  When CONFIG_SND_HDA_INTEL is also disabled,
the fallback is set to SND_INTEL_DSP_DRIVER_ANY type, just to be sure.

Reported-by: Askar Safin <safinaskar@gmail.com>
Closes: https://lore.kernel.org/all/20251014034156.4480-1-safinaskar@gmail.com/
Tested-by: Askar Safin <safinaskar@gmail.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20251210131553.184404-1-tiwai@suse.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Comprehensive Analysis

### 1. Commit Message Analysis

**Keywords**: "problem", "wrong driver", "failed", "broken"

**Strong positive indicators**:
- `Reported-by: Askar Safin` - Real user encountered this bug
- `Closes:` link - References actual bug report
- `Tested-by: Askar Safin` - Reporter verified the fix works
- `Reviewed-by: Peter Ujfalusi` - Intel audio engineer review
- `Signed-off-by: Takashi Iwai` - ALSA maintainer

### 2. Code Change Analysis

The change is minimal - only 2-3 lines:

```c
// Before:
if (!cfg)
    return SND_INTEL_DSP_DRIVER_ANY;

// After:
if (!cfg)
    return IS_ENABLED(CONFIG_SND_HDA_INTEL) ?
        SND_INTEL_DSP_DRIVER_LEGACY : SND_INTEL_DSP_DRIVER_ANY;
```

**Technical mechanism of the bug**:
1. Config table entries for Alderlake chips are wrapped in `#if
   IS_ENABLED(CONFIG_SND_SOC_SOF_ALDERLAKE)`
2. When that Kconfig is not set, entries are compiled out
3. `snd_intel_dsp_find_config()` returns NULL (no match)
4. Code returns `SND_INTEL_DSP_DRIVER_ANY` - letting any driver bind
5. AVS driver may bind first and fail, leaving no working audio

**Why the fix works**:
- Returns `SND_INTEL_DSP_DRIVER_LEGACY` when `CONFIG_SND_HDA_INTEL` is
  enabled
- The legacy HDA Intel driver then probes successfully
- This matches the behavior at the end of the function (line 742) when
  config entries exist but don't match conditions

### 3. Classification

This is clearly a **bug fix**:
- Fixes wrong driver selection leading to broken audio
- Does not add new features or APIs
- Uses compile-time conditional - zero runtime overhead

### 4. Scope and Risk Assessment

- **Lines changed**: 2-3 lines
- **Files affected**: 1 file
- **Complexity**: Very low - single compile-time conditional
- **Risk**: Very low
  - Uses `IS_ENABLED()` which is compile-time evaluation
  - Preserves original behavior when `CONFIG_SND_HDA_INTEL` is disabled
  - The legacy driver is the conservative/safe fallback

### 5. User Impact

- **Severity**: High - audio completely broken
- **Who is affected**: Users with modern Intel chips (Alderlake, Raptor
  Lake, etc.) without `CONFIG_SND_SOC_SOF_ALDERLAKE` enabled
- **Real-world**: This is a realistic scenario for distribution kernels

### 6. Stability Indicators

- ✓ `Tested-by:` from reporter
- ✓ `Reviewed-by:` from Intel engineer
- ✓ Author is Takashi Iwai (ALSA maintainer - highly experienced)

### 7. Dependency Check

**Stable tree compatibility verified**:
- File exists at `sound/hda/intel-dsp-config.c` in v6.6 and v6.12 stable
- The exact code being modified (`if (!cfg) return
  SND_INTEL_DSP_DRIVER_ANY;`) exists in all active stable kernels
- File was recently moved to `sound/hda/core/intel-dsp-config.c` in
  mainline - stable backport needs path adjustment
- No dependencies on other commits

### Conclusion

This commit meets all stable kernel criteria:
- ✓ Fixes a real, user-reported bug (broken audio)
- ✓ Obviously correct (uses same logic already present elsewhere in the
  function)
- ✓ Small and contained (2-3 lines in one file)
- ✓ No new features or APIs
- ✓ Well-tested (reporter verified)
- ✓ Properly reviewed (Intel engineer + ALSA maintainer)
- ✓ Applies to stable trees (with path adjustment for file location)

The bug causes complete audio failure on modern Intel systems with
certain kernel configurations. The fix is minimal, low-risk, and uses a
compile-time conditional that preserves old behavior as a fallback.

**YES**

 sound/hda/core/intel-dsp-config.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/hda/core/intel-dsp-config.c b/sound/hda/core/intel-dsp-config.c
index 2a9e35cddcf7c..ddb349bc46bbd 100644
--- a/sound/hda/core/intel-dsp-config.c
+++ b/sound/hda/core/intel-dsp-config.c
@@ -710,7 +710,8 @@ int snd_intel_dsp_driver_probe(struct pci_dev *pci)
 	/* find the configuration for the specific device */
 	cfg = snd_intel_dsp_find_config(pci, config_table, ARRAY_SIZE(config_table));
 	if (!cfg)
-		return SND_INTEL_DSP_DRIVER_ANY;
+		return IS_ENABLED(CONFIG_SND_HDA_INTEL) ?
+			SND_INTEL_DSP_DRIVER_LEGACY : SND_INTEL_DSP_DRIVER_ANY;
 
 	if (cfg->flags & FLAG_SOF) {
 		if (cfg->flags & FLAG_SOF_ONLY_IF_SOUNDWIRE &&
-- 
2.51.0

Re: [PATCH AUTOSEL 6.18-6.17] ALSA: hda: intel-dsp-config: Prefer legacy driver as fallback

[Askar Safin]

On Mon, Dec 15, 2025 at 3:41 AM Sasha Levin <sashal@kernel.org> wrote:
>
> From: Takashi Iwai <tiwai@suse.de>
>
> [ Upstream commit 161a0c617ab172bbcda7ce61803addeb2124dbff ]
>
> When config table entries don't match with the device to be probed,
> currently we fall back to SND_INTEL_DSP_DRIVER_ANY, which means to
> allow any drivers to bind with it.
>
[...]
>
> Reported-by: Askar Safin <safinaskar@gmail.com>
> Closes: https://lore.kernel.org/all/20251014034156.4480-1-safinaskar@gmail.com/
> Tested-by: Askar Safin <safinaskar@gmail.com>
> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> Link: https://patch.msgid.link/20251210131553.184404-1-tiwai@suse.de
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---

Please, backport this to 82d9d54a6c0e .
82d9d54a6c0e is commit, which introduced "intel-dsp-config.c".

-- 
Askar Safin

Re: [PATCH AUTOSEL 6.18-6.17] ALSA: hda: intel-dsp-config: Prefer legacy driver as fallback

[Sasha Levin]

On Tue, Dec 16, 2025 at 02:29:14AM +0300, Askar Safin wrote:
>On Mon, Dec 15, 2025 at 3:41 AM Sasha Levin <sashal@kernel.org> wrote:
>>
>> From: Takashi Iwai <tiwai@suse.de>
>>
>> [ Upstream commit 161a0c617ab172bbcda7ce61803addeb2124dbff ]
>>
>> When config table entries don't match with the device to be probed,
>> currently we fall back to SND_INTEL_DSP_DRIVER_ANY, which means to
>> allow any drivers to bind with it.
>>
>[...]
>>
>> Reported-by: Askar Safin <safinaskar@gmail.com>
>> Closes: https://lore.kernel.org/all/20251014034156.4480-1-safinaskar@gmail.com/
>> Tested-by: Askar Safin <safinaskar@gmail.com>
>> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
>> Signed-off-by: Takashi Iwai <tiwai@suse.de>
>> Link: https://patch.msgid.link/20251210131553.184404-1-tiwai@suse.de
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> ---
>
>Please, backport this to 82d9d54a6c0e .
>82d9d54a6c0e is commit, which introduced "intel-dsp-config.c".

Looks like that commit is already in all trees.

-- 
Thanks,
Sasha

Re: [PATCH AUTOSEL 6.18-6.17] ALSA: hda: intel-dsp-config: Prefer legacy driver as fallback

[Askar Safin]

On Wed, Jan 7, 2026 at 2:16 PM Sasha Levin <sashal@kernel.org> wrote:
> >Please, backport this to 82d9d54a6c0e .
> >82d9d54a6c0e is commit, which introduced "intel-dsp-config.c".
>
> Looks like that commit is already in all trees.

You mean that 82d9d54a6c0e is in all trees? Okay, then,
please, backport 161a0c617ab172bbcda7ce61803addeb2124dbff
to all trees.

-- 
Askar Safin

Re: [PATCH AUTOSEL 6.18-6.17] ALSA: hda: intel-dsp-config: Prefer legacy driver as fallback

[Greg KH]

On Sun, Jan 11, 2026 at 03:04:47PM +0300, Askar Safin wrote:
> On Wed, Jan 7, 2026 at 2:16 PM Sasha Levin <sashal@kernel.org> wrote:
> > >Please, backport this to 82d9d54a6c0e .
> > >82d9d54a6c0e is commit, which introduced "intel-dsp-config.c".
> >
> > Looks like that commit is already in all trees.
> 
> You mean that 82d9d54a6c0e is in all trees? Okay, then,
> please, backport 161a0c617ab172bbcda7ce61803addeb2124dbff
> to all trees.

Why?  I see no context here :(

Re: [PATCH AUTOSEL 6.18-6.17] ALSA: hda: intel-dsp-config: Prefer legacy driver as fallback

[Askar Safin]

On Sun, Jan 11, 2026 at 3:24 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > You mean that 82d9d54a6c0e is in all trees? Okay, then,
> > please, backport 161a0c617ab172bbcda7ce61803addeb2124dbff
> > to all trees.
>
> Why?  I see no context here :(

Please, backport 161a0c617ab1 to all stable kernels, which have 82d9d54a6c0e.

161a0c617ab1 fixes bug, reported by me here:
https://lore.kernel.org/all/20251014034156.4480-1-safinaskar@gmail.com/ .

I did bisect and found that 2d9223d2d64c is the culprit. But then Takashi Iwai
explained that the bug appeared earlier:
https://lore.kernel.org/all/87345iebky.wl-tiwai@suse.de/ .
Iwai said: "the bug itself was introduced
from the very beginning, and it could hit earlier".

I assume "the very beginning" here should be interpreted as
"commit, where intel-dsp-config.c appeared", because the fix
modifies "intel-dsp-config.c".

"intel-dsp-config.c" introduced in 82d9d54a6c0e, so
161a0c617ab1 should be backported to all kernels, which
have 82d9d54a6c0e.

-- 
Askar Safin

Re: [PATCH AUTOSEL 6.18-6.17] ALSA: hda: intel-dsp-config: Prefer legacy driver as fallback

[Greg KH]

On Sun, Jan 11, 2026 at 07:01:53PM +0300, Askar Safin wrote:
> On Sun, Jan 11, 2026 at 3:24 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > You mean that 82d9d54a6c0e is in all trees? Okay, then,
> > > please, backport 161a0c617ab172bbcda7ce61803addeb2124dbff
> > > to all trees.
> >
> > Why?  I see no context here :(
> 
> Please, backport 161a0c617ab1 to all stable kernels, which have 82d9d54a6c0e.
> 
> 161a0c617ab1 fixes bug, reported by me here:
> https://lore.kernel.org/all/20251014034156.4480-1-safinaskar@gmail.com/ .
> 
> I did bisect and found that 2d9223d2d64c is the culprit. But then Takashi Iwai
> explained that the bug appeared earlier:
> https://lore.kernel.org/all/87345iebky.wl-tiwai@suse.de/ .
> Iwai said: "the bug itself was introduced
> from the very beginning, and it could hit earlier".
> 
> I assume "the very beginning" here should be interpreted as
> "commit, where intel-dsp-config.c appeared", because the fix
> modifies "intel-dsp-config.c".
> 
> "intel-dsp-config.c" introduced in 82d9d54a6c0e, so
> 161a0c617ab1 should be backported to all kernels, which
> have 82d9d54a6c0e.

This only applies to one tree (6.18.y), can you provide working
backports for all of the other stable trees?

thanks,

greg k-h

[PATCH 6.12.y] ALSA: hda: intel-dsp-config: Prefer legacy driver as fallback

[Askar Safin]

From: Takashi Iwai <tiwai@suse.de>

[ Upstream commit 161a0c617ab172bbcda7ce61803addeb2124dbff ]

When config table entries don't match with the device to be probed,
currently we fall back to SND_INTEL_DSP_DRIVER_ANY, which means to
allow any drivers to bind with it.

This was set so with the assumption (or hope) that all controller
drivers should cover the devices generally, but in practice, this
caused a problem as reported recently.  Namely, when a specific
kconfig for SOF isn't set for the modern Intel chips like Alderlake,
a wrong driver (AVS) got probed and failed.  This is because we have
entries like:

 #if IS_ENABLED(CONFIG_SND_SOC_SOF_ALDERLAKE)
 /* Alder Lake / Raptor Lake */
        {
                .flags = FLAG_SOF | FLAG_SOF_ONLY_IF_DMIC_OR_SOUNDWIRE,
                .device = PCI_DEVICE_ID_INTEL_HDA_ADL_S,
        },
 ....
 #endif

so this entry is effective only when CONFIG_SND_SOC_SOF_ALDERLAKE is
set.  If not set, there is no matching entry, hence it returns
SND_INTEL_DSP_DRIVER_ANY as fallback.  OTOH, if the kconfig is set, it
explicitly falls back to SND_INTEL_DSP_DRIVER_LEGACY when no DMIC or
SoundWire is found -- that was the working scenario.  That being said,
the current setup may be broken for modern Intel chips that are
supposed to work with either SOF or legacy driver when the
corresponding kconfig were missing.

For addressing the problem above, this patch changes the fallback
driver to the legacy driver, i.e. return SND_INTEL_DSP_DRIVER_LEGACY
type as much as possible.  When CONFIG_SND_HDA_INTEL is also disabled,
the fallback is set to SND_INTEL_DSP_DRIVER_ANY type, just to be sure.

Reported-by: Askar Safin <safinaskar@gmail.com>
Closes: https://lore.kernel.org/all/20251014034156.4480-1-safinaskar@gmail.com/
Tested-by: Askar Safin <safinaskar@gmail.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20251210131553.184404-1-tiwai@suse.de
Signed-off-by: Askar Safin <safinaskar@gmail.com>
---
 sound/hda/intel-dsp-config.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/hda/intel-dsp-config.c b/sound/hda/intel-dsp-config.c
index 34825b2f3b10..3246705ddb19 100644
--- a/sound/hda/intel-dsp-config.c
+++ b/sound/hda/intel-dsp-config.c
@@ -676,7 +676,8 @@ int snd_intel_dsp_driver_probe(struct pci_dev *pci)
 	/* find the configuration for the specific device */
 	cfg = snd_intel_dsp_find_config(pci, config_table, ARRAY_SIZE(config_table));
 	if (!cfg)
-		return SND_INTEL_DSP_DRIVER_ANY;
+		return IS_ENABLED(CONFIG_SND_HDA_INTEL) ?
+			SND_INTEL_DSP_DRIVER_LEGACY : SND_INTEL_DSP_DRIVER_ANY;
 
 	if (cfg->flags & FLAG_SOF) {
 		if (cfg->flags & FLAG_SOF_ONLY_IF_SOUNDWIRE &&

base-commit: 39cb076c7dc7e44e3cab5c82ffda16a550ed8436
-- 
2.47.3

Re: [PATCH AUTOSEL 6.18-6.17] ALSA: hda: intel-dsp-config: Prefer legacy driver as fallback

[Askar Safin]

On Mon, Jan 12, 2026 at 1:54 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> On Sun, Jan 11, 2026 at 07:01:53PM +0300, Askar Safin wrote:
> > On Sun, Jan 11, 2026 at 3:24 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > Why?  I see no context here :(
> >
> > Please, backport 161a0c617ab1 to all stable kernels, which have 82d9d54a6c0e.
> >
> > 161a0c617ab1 fixes bug, reported by me here:
> > https://lore.kernel.org/all/20251014034156.4480-1-safinaskar@gmail.com/ .
> >
> > I did bisect and found that 2d9223d2d64c is the culprit. But then Takashi Iwai
> > explained that the bug appeared earlier:
> > https://lore.kernel.org/all/87345iebky.wl-tiwai@suse.de/ .
> > Iwai said: "the bug itself was introduced
> > from the very beginning, and it could hit earlier".
> >
> > I assume "the very beginning" here should be interpreted as
> > "commit, where intel-dsp-config.c appeared", because the fix
> > modifies "intel-dsp-config.c".
> >
> > "intel-dsp-config.c" introduced in 82d9d54a6c0e, so
> > 161a0c617ab1 should be backported to all kernels, which
> > have 82d9d54a6c0e.
>
> This only applies to one tree (6.18.y), can you provide working
> backports for all of the other stable trees?

I just sent backport to 6.12.y.   I hope this backport will also apply
cleanly to older trees.

-- 
Askar Safin

[PATCH AUTOSEL 6.18-6.12] ASoC: rockchip: Fix Wvoid-pointer-to-enum-cast warning (again)

[Sasha Levin]

From: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

[ Upstream commit 57d508b5f718730f74b11e0dc9609ac7976802d1 ]

'version' is an enum, thus cast of pointer on 64-bit compile test with
clang W=1 causes:

  rockchip_pdm.c:583:17: error: cast to smaller integer type 'enum rk_pdm_version' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]

This was already fixed in commit 49a4a8d12612 ("ASoC: rockchip: Fix
Wvoid-pointer-to-enum-cast warning") but then got bad in
commit 9958d85968ed ("ASoC: Use device_get_match_data()").

Discussion on LKML also pointed out that 'uintptr_t' is not the correct
type and either 'kernel_ulong_t' or 'unsigned long' should be used,
with several arguments towards the latter [1].

Link: https://lore.kernel.org/r/CAMuHMdX7t=mabqFE5O-Cii3REMuyaePHmqX+j_mqyrn6XXzsoA@mail.gmail.com/ [1]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251203141644.106459-2-krzysztof.kozlowski@oss.qualcomm.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 Analysis

### What the commit fixes
This is a **build fix** that prevents a compilation error when building
with clang and W=1:
```
error: cast to smaller integer type 'enum rk_pdm_version' from 'const
void *' [-Werror,-Wvoid-pointer-to-enum-cast]
```

The issue is that on 64-bit systems, casting directly from `const void
*` (64 bits) to an enum (typically 32 bits) triggers a truncation
warning. Using `(unsigned long)` as an intermediate cast avoids this
because `unsigned long` matches the pointer size.

### Classification
This falls clearly into the **BUILD FIX** exception category which is
explicitly allowed for stable trees. Build fixes that prevent
compilation are critical for users who need to build the kernel.

### Scope and Risk
- **Change**: Single line - only changing the cast type
- **Files touched**: 1 file
- **Risk**: Extremely low - the runtime behavior is identical; only the
  compile-time representation differs
- **Functional equivalence**: The value stored in `pdm->version` is the
  same either way

### Applicability to Stable Trees
The regressing commit 9958d85968ed went into v6.7-rc1. Therefore:
- Stable trees **v6.6.y and earlier**: NOT affected (don't have the
  regression)
- Stable trees **v6.7.y and later**: Affected and would benefit from
  this fix

### Stable Criteria Assessment
| Criterion | Assessment |
|-----------|------------|
| Obviously correct | ✓ Yes - standard pattern for void pointer to enum
cast |
| Fixes real bug | ✓ Yes - compilation failure |
| Small scope | ✓ Yes - 1 line change |
| No new features | ✓ Correct - pure bug fix |
| Tested | ✓ Accepted by maintainer |

### Additional Factors
- This is a **regression fix** - the same issue was previously fixed in
  commit 49a4a8d12612 but regressed
- LKML discussion confirms `unsigned long` as the appropriate fix
- Signed off by both author and subsystem maintainer (Mark Brown)

### Risk vs Benefit
- **Risk**: Near zero - compile-time only change, no runtime behavior
  modification
- **Benefit**: Enables compilation with clang W=1 on 64-bit platforms

This is an excellent stable backport candidate. It's a minimal, low-risk
build fix that allows users to compile the kernel in a common
configuration. Build fixes are explicitly mentioned as appropriate for
stable trees, and this one is as safe as they come - a single-line cast
change with no runtime impact.

**YES**

 sound/soc/rockchip/rockchip_pdm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/rockchip/rockchip_pdm.c b/sound/soc/rockchip/rockchip_pdm.c
index c1ee470ec6079..c69cdd6f24994 100644
--- a/sound/soc/rockchip/rockchip_pdm.c
+++ b/sound/soc/rockchip/rockchip_pdm.c
@@ -580,7 +580,7 @@ static int rockchip_pdm_probe(struct platform_device *pdev)
 	if (!pdm)
 		return -ENOMEM;
 
-	pdm->version = (enum rk_pdm_version)device_get_match_data(&pdev->dev);
+	pdm->version = (unsigned long)device_get_match_data(&pdev->dev);
 	if (pdm->version == RK_PDM_RK3308) {
 		pdm->reset = devm_reset_control_get(&pdev->dev, "pdm-m");
 		if (IS_ERR(pdm->reset))
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] ASoC: rockchip: Fix Wvoid-pointer-to-enum-cast warning (again)

[Sasha Levin]

From: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

[ Upstream commit 57d508b5f718730f74b11e0dc9609ac7976802d1 ]

'version' is an enum, thus cast of pointer on 64-bit compile test with
clang W=1 causes:

  rockchip_pdm.c:583:17: error: cast to smaller integer type 'enum rk_pdm_version' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]

This was already fixed in commit 49a4a8d12612 ("ASoC: rockchip: Fix
Wvoid-pointer-to-enum-cast warning") but then got bad in
commit 9958d85968ed ("ASoC: Use device_get_match_data()").

Discussion on LKML also pointed out that 'uintptr_t' is not the correct
type and either 'kernel_ulong_t' or 'unsigned long' should be used,
with several arguments towards the latter [1].

Link: https://lore.kernel.org/r/CAMuHMdX7t=mabqFE5O-Cii3REMuyaePHmqX+j_mqyrn6XXzsoA@mail.gmail.com/ [1]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251203141644.106459-2-krzysztof.kozlowski@oss.qualcomm.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 Analysis

### What the commit fixes
This is a **build fix** that prevents a compilation error when building
with clang and W=1:
```
error: cast to smaller integer type 'enum rk_pdm_version' from 'const
void *' [-Werror,-Wvoid-pointer-to-enum-cast]
```

The issue is that on 64-bit systems, casting directly from `const void
*` (64 bits) to an enum (typically 32 bits) triggers a truncation
warning. Using `(unsigned long)` as an intermediate cast avoids this
because `unsigned long` matches the pointer size.

### Classification
This falls clearly into the **BUILD FIX** exception category which is
explicitly allowed for stable trees. Build fixes that prevent
compilation are critical for users who need to build the kernel.

### Scope and Risk
- **Change**: Single line - only changing the cast type
- **Files touched**: 1 file
- **Risk**: Extremely low - the runtime behavior is identical; only the
  compile-time representation differs
- **Functional equivalence**: The value stored in `pdm->version` is the
  same either way

### Applicability to Stable Trees
The regressing commit 9958d85968ed went into v6.7-rc1. Therefore:
- Stable trees **v6.6.y and earlier**: NOT affected (don't have the
  regression)
- Stable trees **v6.7.y and later**: Affected and would benefit from
  this fix

### Stable Criteria Assessment
| Criterion | Assessment |
|-----------|------------|
| Obviously correct | ✓ Yes - standard pattern for void pointer to enum
cast |
| Fixes real bug | ✓ Yes - compilation failure |
| Small scope | ✓ Yes - 1 line change |
| No new features | ✓ Correct - pure bug fix |
| Tested | ✓ Accepted by maintainer |

### Additional Factors
- This is a **regression fix** - the same issue was previously fixed in
  commit 49a4a8d12612 but regressed
- LKML discussion confirms `unsigned long` as the appropriate fix
- Signed off by both author and subsystem maintainer (Mark Brown)

### Risk vs Benefit
- **Risk**: Near zero - compile-time only change, no runtime behavior
  modification
- **Benefit**: Enables compilation with clang W=1 on 64-bit platforms

This is an excellent stable backport candidate. It's a minimal, low-risk
build fix that allows users to compile the kernel in a common
configuration. Build fixes are explicitly mentioned as appropriate for
stable trees, and this one is as safe as they come - a single-line cast
change with no runtime impact.

**YES**

 sound/soc/rockchip/rockchip_pdm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/rockchip/rockchip_pdm.c b/sound/soc/rockchip/rockchip_pdm.c
index c1ee470ec6079..c69cdd6f24994 100644
--- a/sound/soc/rockchip/rockchip_pdm.c
+++ b/sound/soc/rockchip/rockchip_pdm.c
@@ -580,7 +580,7 @@ static int rockchip_pdm_probe(struct platform_device *pdev)
 	if (!pdm)
 		return -ENOMEM;
 
-	pdm->version = (enum rk_pdm_version)device_get_match_data(&pdev->dev);
+	pdm->version = (unsigned long)device_get_match_data(&pdev->dev);
 	if (pdm->version == RK_PDM_RK3308) {
 		pdm->reset = devm_reset_control_get(&pdev->dev, "pdm-m");
 		if (IS_ERR(pdm->reset))
-- 
2.51.0


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH AUTOSEL 6.18-5.10] NFSv4: ensure the open stateid seqid doesn't go backwards

[Sasha Levin]

From: Scott Mayhew <smayhew@redhat.com>

[ Upstream commit 2e47c3cc64b44b0b06cd68c2801db92ff143f2b2 ]

We have observed an NFSv4 client receiving a LOCK reply with a status of
NFS4ERR_OLD_STATEID and subsequently retrying the LOCK request with an
earlier seqid value in the stateid.  As this was for a new lockowner,
that would imply that nfs_set_open_stateid_locked() had updated the open
stateid seqid with an earlier value.

Looking at nfs_set_open_stateid_locked(), if the incoming seqid is out
of sequence, the task will sleep on the state->waitq for up to 5
seconds.  If the task waits for the full 5 seconds, then after finishing
the wait it'll update the open stateid seqid with whatever value the
incoming seqid has.  If there are multiple waiters in this scenario,
then the last one to perform said update may not be the one with the
highest seqid.

Add a check to ensure that the seqid can only be incremented, and add a
tracepoint to indicate when old seqids are skipped.

Signed-off-by: Scott Mayhew <smayhew@redhat.com>
Reviewed-by: Benjamin Coddington <bcodding@hammerspace.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis Summary

### 3. Bug Classification and Severity

**This is clearly a BUG FIX**, not a feature addition:
- **Observed production issue**: NFS4ERR_OLD_STATEID errors
- **Race condition bug**: Multiple waiters can corrupt stateid ordering
- **Protocol compliance**: Client violates NFSv4 protocol by using stale
  seqids
- **Potential data integrity risk**: Lock failures can lead to data
  corruption in concurrent access scenarios

**The root cause explained:**
When `nfs_set_open_stateid_locked()` detects an out-of-sequence stateid,
it waits up to 5 seconds on `state->waitq`. If multiple waiters all
timeout (status = -EAGAIN), they all proceed to update the stateid. The
last one wins, but it may have an **older** seqid than an earlier
updater. This causes seqid to go backwards.

**The fix:**
Before allowing the update after a timeout, check if the incoming
stateid is actually newer than the current one using
`nfs4_stateid_is_newer()`. If not, skip the update entirely and return
early.

### 4. Scope and Risk Assessment

| Aspect | Assessment |
|--------|------------|
| Lines changed | ~15 lines in core logic |
| Files touched | 2 (nfs4proc.c, nfs4trace.h) |
| Dependencies | Uses existing helpers from 2019 |
| New APIs | None |
| Risk | LOW - adds a missing safety check |

The tracepoint addition (`nfs4_open_stateid_update_skip`) uses an
existing event class - it's purely diagnostic.

### 5. Stable Criteria Checklist

- ✅ **Obviously correct**: Simple check using well-established helper
  functions
- ✅ **Fixes real bug**: Observed NFS4ERR_OLD_STATEID in production
- ✅ **Important issue**: I/O failures, potential data integrity issues
- ✅ **Small and contained**: ~15 lines, single function fix
- ✅ **No new features**: Pure bug fix with diagnostic tracepoint
- ✅ **No new APIs**: Uses existing nfs4_stateid_* helpers from 2019
- ✅ **Reviewed**: By Benjamin Coddington (NFS expert)
- ✅ **Signed-off**: By Trond Myklebust (primary NFS maintainer)

### 6. User Impact

- **Who is affected**: Any NFSv4 user with concurrent file access
  patterns
- **Severity**: Medium-High - can cause I/O failures, lock errors, and
  potential data corruption
- **Enterprise impact**: NFS is heavily used in enterprise environments;
  this is an important fix

### 7. Dependencies Check

The helper functions used (`nfs4_stateid_match_other`,
`nfs4_stateid_is_newer`) have been in the kernel since 2019 and are used
by 24 and 11 callers respectively. They will exist in all active stable
trees (6.1.y, 6.6.y, etc.).

### Conclusion

This is an excellent stable backport candidate:
- Fixes a real, observed bug that causes protocol violations and I/O
  failures
- Small, surgical fix with clear logic
- Uses existing infrastructure - no dependency issues
- Reviewed and signed-off by NFS maintainers
- Low risk of regression - it adds a missing safety check

The fix prevents NFSv4 stateid seqid from going backwards, which is a
correctness issue that can impact production NFS users.

**YES**

 fs/nfs/nfs4proc.c  | 13 +++++++++++--
 fs/nfs/nfs4trace.h |  1 +
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 93c6ce04332b8..d1ad2ef2ee6f9 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -1780,8 +1780,17 @@ static void nfs_set_open_stateid_locked(struct nfs4_state *state,
 		if (nfs_stateid_is_sequential(state, stateid))
 			break;
 
-		if (status)
-			break;
+		if (status) {
+			if (nfs4_stateid_match_other(stateid, &state->open_stateid) &&
+			    !nfs4_stateid_is_newer(stateid, &state->open_stateid)) {
+				trace_nfs4_open_stateid_update_skip(state->inode,
+								    stateid, status);
+				return;
+			} else {
+				break;
+			}
+		}
+
 		/* Rely on seqids for serialisation with NFSv4.0 */
 		if (!nfs4_has_session(NFS_SERVER(state->inode)->nfs_client))
 			break;
diff --git a/fs/nfs/nfs4trace.h b/fs/nfs/nfs4trace.h
index 9776d220cec33..6285128e631a5 100644
--- a/fs/nfs/nfs4trace.h
+++ b/fs/nfs/nfs4trace.h
@@ -1353,6 +1353,7 @@ DEFINE_NFS4_INODE_STATEID_EVENT(nfs4_setattr);
 DEFINE_NFS4_INODE_STATEID_EVENT(nfs4_delegreturn);
 DEFINE_NFS4_INODE_STATEID_EVENT(nfs4_open_stateid_update);
 DEFINE_NFS4_INODE_STATEID_EVENT(nfs4_open_stateid_update_wait);
+DEFINE_NFS4_INODE_STATEID_EVENT(nfs4_open_stateid_update_skip);
 DEFINE_NFS4_INODE_STATEID_EVENT(nfs4_close_stateid_update_wait);
 
 DECLARE_EVENT_CLASS(nfs4_getattr_event,
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.1] bcache: fix improper use of bi_end_io

[Sasha Levin]

From: Shida Zhang <zhangshida@kylinos.cn>

[ Upstream commit 53280e398471f0bddbb17b798a63d41264651325 ]

Don't call bio->bi_end_io() directly. Use the bio_endio() helper
function instead, which handles completion more safely and uniformly.

Suggested-by: Christoph Hellwig <hch@infradead.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Shida Zhang <zhangshida@kylinos.cn>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of bcache commit: "fix improper use of bi_end_io"

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly indicates this is a **bug fix** addressing
improper use of the block I/O completion API. Key signals:
- Subject explicitly says "fix improper use"
- Body explains the correct API (`bio_endio()`) should be used instead
  of direct `bi_end_io()` calls
- Suggested and Reviewed by Christoph Hellwig - one of the most
  respected Linux kernel developers, particularly in block layer code

### 2. CODE CHANGE ANALYSIS

The commit makes three changes in `drivers/md/bcache/request.c`:

**Change 1** (detached_dev_end_io, line 1107):
```c
- bio->bi_end_io(bio);
+       bio_endio(bio);
```
After restoring the original `bi_end_io`, uses proper API for
completion.

**Change 2** (detached_dev_do_request error path, line 1122):
```c
- bio->bi_end_io(bio);
+       bio_endio(bio);
```
Error path when `kzalloc` fails - uses proper API.

**Change 3** (detached_dev_do_request discard handling, line 1139):
```c
- bio->bi_end_io(bio);
+       detached_dev_end_io(bio);
```
**This is the most critical fix.** At this point, `bio->bi_end_io` has
already been reassigned to `detached_dev_end_io`. The old code was
calling the *saved* original handler directly, completely bypassing the
accounting and cleanup in `detached_dev_end_io()`. This could cause:
- Missing I/O accounting (`bio_end_io_acct_remapped` never called)
- Memory leak (ddip structure never freed)
- Incorrect error handling for backing device

### 3. WHY THIS IS A BUG

`bio_endio()` does more than just calling `bi_end_io()`:
- Handles bio chaining/splitting properly
- Manages completion accounting
- Ensures proper memory barriers
- Provides unified completion path expected by block layer

Bypassing this function can cause:
- Incorrect I/O statistics
- Race conditions in bio completion
- Potential memory issues
- Missing cleanup (especially Change 3)

### 4. CLASSIFICATION

- **Bug fix**: Yes - corrects improper API usage
- **Feature addition**: No
- **Security**: Not explicitly, but improper completion could lead to
  memory issues

### 5. SCOPE AND RISK ASSESSMENT

| Factor | Assessment |
|--------|------------|
| Lines changed | 3 lines |
| Files touched | 1 file |
| Complexity | Very low - simple API call substitution |
| Subsystem | bcache (mature, stable subsystem) |
| Risk | Very low - using proper API is strictly safer |

### 6. USER IMPACT

- **Affected users**: bcache users (SSD caching in front of HDDs)
- **Severity**: Medium - Change 3 especially could cause I/O accounting
  issues and memory leaks for discards on devices without discard
  support
- **Visibility**: Subtle issues that may manifest as accounting bugs or
  resource leaks

### 7. STABILITY INDICATORS

- **Reviewed-by: Christoph Hellwig** - block layer maintainer provides
  high confidence
- **Suggested-by: Christoph Hellwig** - issue identified by expert
  during code review
- `bio_endio()` is a fundamental, long-standing block layer API - no
  dependency concerns

### 8. DEPENDENCY CHECK

- `bio_endio()` has existed for many years in all stable kernels
- bcache has been in mainline since ~3.10
- No dependencies on other commits
- Should apply cleanly to any stable tree with bcache

### CONCLUSION

This commit meets all stable kernel criteria:

1. **Obviously correct**: Uses the documented, proper block layer API
2. **Fixes real bugs**: Third change especially fixes missing
   cleanup/accounting
3. **Small and contained**: Only 3 one-line changes
4. **Reviewed by expert**: Christoph Hellwig's review carries
   significant weight
5. **No new features**: Pure correctness fix
6. **Low risk**: Switching to proper API cannot introduce new bugs

The fix is surgical, addresses genuine API misuse that causes real
issues (particularly the discard path), has top-tier review, and carries
essentially no regression risk.

**YES**

 drivers/md/bcache/request.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index af345dc6fde14..82fdea7dea7aa 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -1104,7 +1104,7 @@ static void detached_dev_end_io(struct bio *bio)
 	}
 
 	kfree(ddip);
-	bio->bi_end_io(bio);
+	bio_endio(bio);
 }
 
 static void detached_dev_do_request(struct bcache_device *d, struct bio *bio,
@@ -1121,7 +1121,7 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio,
 	ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
 	if (!ddip) {
 		bio->bi_status = BLK_STS_RESOURCE;
-		bio->bi_end_io(bio);
+		bio_endio(bio);
 		return;
 	}
 
@@ -1136,7 +1136,7 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio,
 
 	if ((bio_op(bio) == REQ_OP_DISCARD) &&
 	    !bdev_max_discard_sectors(dc->bdev))
-		bio->bi_end_io(bio);
+		detached_dev_end_io(bio);
 	else
 		submit_bio_noacct(bio);
 }
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] NFS: Fix up the automount fs_context to use the correct cred

[Sasha Levin]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

[ Upstream commit a2a8fc27dd668e7562b5326b5ed2f1604cb1e2e9 ]

When automounting, the fs_context should be fixed up to use the cred
from the parent filesystem, since the operation is just extending the
namespace. Authorisation to enter that namespace will already have been
provided by the preceding lookup.

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## NFS Automount Credential Fix Analysis

### Commit Overview
This commit fixes a credential handling bug in NFS automount operations.
When automounting (crossing a mountpoint boundary within an NFS export),
the filesystem context should inherit credentials from the parent
filesystem rather than using potentially incorrect default credentials.

### Code Change Analysis

The change adds 4 lines to `nfs_d_automount()` in `fs/nfs/namespace.c`:

```c
if (fc->cred != server->cred) {
    put_cred(fc->cred);
    fc->cred = get_cred(server->cred);
}
```

**Technical mechanism:**
- When `fs_context_for_submount()` creates a new fs_context, it may not
  inherit the proper credentials from the parent NFS mount
- The fix explicitly checks if the credentials differ and replaces them
  with the parent server's credentials
- This follows proper reference counting: `put_cred()` releases the old
  reference, `get_cred()` acquires a new reference to the server's
  credentials

**Pattern consistency:**
The fix follows an identical pattern already present in the same
function for network namespace handling:
```c
if (fc->net_ns != client->cl_net) {
    put_net(fc->net_ns);
    fc->net_ns = get_net(client->cl_net);
}
```

This demonstrates the code is consistent with existing practices and is
obviously correct.

### Bug Impact

**Without this fix:**
- Automounted NFS submounts could use wrong credentials (likely task
  credentials instead of mount credentials)
- This can cause authorization failures or inconsistent access behavior
- Users may experience permission denied errors when traversing NFS
  automounts
- Potential security implications with credential mismatch

**User scenarios affected:**
- Enterprise NFS deployments with automount configurations
- Users crossing mountpoints within NFS exports
- Any NFS setup using submounts/referrals

### Stable Kernel Criteria Assessment

| Criteria | Assessment |
|----------|------------|
| Obviously correct | ✅ Follows existing pattern, proper refcounting |
| Fixes real bug | ✅ Credential mismatch in automount |
| Important issue | ✅ Authentication/authorization affects NFS usability
|
| Small and contained | ✅ 4 lines in single function |
| No new features | ✅ Bug fix only |
| Clean backport | ✅ Localized change |

### Risk Assessment

**Low risk:**
- Change is minimal (4 lines)
- Follows existing code pattern exactly
- Author is Trond Myklebust, the NFS maintainer
- Proper reference counting used
- No new APIs or behavioral changes
- Isolated to automount path

**No dependencies identified:**
- Uses standard NFS server structure fields (`server->cred`)
- Uses standard fs_context fields (`fc->cred`)
- These structures have existed for years in stable kernels

### Author Credibility

Trond Myklebust is the long-time NFS maintainer and this is core NFS
code within his area of expertise. This adds significant confidence to
the fix's correctness.

### Conclusion

This is a clear, straightforward bug fix for NFS automount credential
handling:
- Surgically small (4 lines)
- Fixes a real functional bug affecting NFS users
- Follows existing patterns in the same function
- Written by the NFS maintainer
- Low regression risk
- No new features or API changes

The fix ensures proper credential propagation during NFS automount
operations, which is critical for correct authorization behavior. This
is exactly the type of small, contained bug fix that stable trees are
designed to accept.

**YES**

 fs/nfs/namespace.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/nfs/namespace.c b/fs/nfs/namespace.c
index 5a4d193da1a98..30430eaa77b08 100644
--- a/fs/nfs/namespace.c
+++ b/fs/nfs/namespace.c
@@ -169,6 +169,11 @@ struct vfsmount *nfs_d_automount(struct path *path)
 	if (!ctx->clone_data.fattr)
 		goto out_fc;
 
+	if (fc->cred != server->cred) {
+		put_cred(fc->cred);
+		fc->cred = get_cred(server->cred);
+	}
+
 	if (fc->net_ns != client->cl_net) {
 		put_net(fc->net_ns);
 		fc->net_ns = get_net(client->cl_net);
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.1] smb/client: fix NT_STATUS_DEVICE_DOOR_OPEN value

[Sasha Levin]

From: ChenXiaoSong <chenxiaosong@kylinos.cn>

[ Upstream commit b2b50fca34da5ec231008edba798ddf92986bd7f ]

This was reported by the KUnit tests in the later patches.

See MS-ERREF 2.3.1 STATUS_DEVICE_DOOR_OPEN. Keep it consistent with the
value in the documentation.

Signed-off-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: smb/client: fix NT_STATUS_DEVICE_DOOR_OPEN value

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly indicates this is fixing an incorrect
constant value:
- A KUnit test caught the bug
- References Microsoft documentation (MS-ERREF 2.3.1
  STATUS_DEVICE_DOOR_OPEN)
- Goal is to align with official Microsoft specification

### 2. CODE CHANGE ANALYSIS

The change is a single-line fix in `fs/smb/client/nterr.h`:

```c
-#define NT_STATUS_DEVICE_DOOR_OPEN 0x80000288
+#define NT_STATUS_DEVICE_DOOR_OPEN 0x80000289
```

**The Bug:** Looking at the context, I can see the critical issue:
- `NT_STATUS_DEVICE_REQUIRES_CLEANING` = `0x80000288`
- `NT_STATUS_DEVICE_DOOR_OPEN` = `0x80000288` (WRONG - duplicate value!)

Both status codes had the same value, which is clearly incorrect. These
are NT status codes that should be unique. According to Microsoft's MS-
ERREF specification, the correct values should be:
- `NT_STATUS_DEVICE_REQUIRES_CLEANING` = `0x80000288`
- `NT_STATUS_DEVICE_DOOR_OPEN` = `0x80000289`

This is a classic copy-paste error or transcription mistake when the
values were originally added.

### 3. CLASSIFICATION

- **Bug fix**: Yes - correcting a wrong constant value
- **Feature addition**: No
- **Exception category**: N/A - this is a straightforward data
  correction

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed**: 1
- **Files touched**: 1 (header file with constant definitions)
- **Complexity**: Trivial
- **Risk of regression**: Virtually zero - only changes which error code
  is mapped to which value

The fix is as minimal and surgical as possible. Changing a constant from
an incorrect value to the correct documented value cannot introduce new
bugs.

### 5. USER IMPACT

These status codes relate to device media handling (tape drives,
removable media):
- `NT_STATUS_DEVICE_REQUIRES_CLEANING` - device needs cleaning
- `NT_STATUS_DEVICE_DOOR_OPEN` - device door is open

Without this fix, SMB clients receiving `NT_STATUS_DEVICE_DOOR_OPEN`
from a server would incorrectly interpret it as
`NT_STATUS_DEVICE_REQUIRES_CLEANING`. While these are relatively obscure
errors, correct protocol implementation matters for:
- Proper error reporting to users
- Automated error handling systems
- Protocol compliance

### 6. STABILITY INDICATORS

- **Acked-by**: Paulo Alcantara (Red Hat) - well-known SMB subsystem
  reviewer
- **Signed-off-by**: Steve French - SMB/CIFS maintainer
- **Testing**: Found by KUnit tests, indicating solid test coverage

### 7. DEPENDENCY CHECK

- No dependencies on other commits
- The header file exists in all stable trees with SMB client support
- Will apply cleanly

### CONCLUSION

This is an ideal stable backport candidate:

1. **Obviously correct**: Just fixing a wrong constant to match official
   documentation
2. **Fixes a real bug**: Duplicate/incorrect NT status code values
3. **Small and contained**: Single line change to a constant definition
4. **No new features**: Pure correction
5. **Zero regression risk**: The worst case is unchanged behavior for
   code that was incorrectly handling the duplicate value
6. **Properly reviewed**: Acked by maintainer

The fix ensures correct SMB protocol behavior by aligning NT status
codes with Microsoft's official specification. It's a textbook example
of what belongs in stable trees.

**YES**

 fs/smb/client/nterr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/smb/client/nterr.h b/fs/smb/client/nterr.h
index e3a607b45e719..b3516c71cff77 100644
--- a/fs/smb/client/nterr.h
+++ b/fs/smb/client/nterr.h
@@ -44,7 +44,7 @@ extern const struct nt_err_code_struct nt_errs[];
 #define NT_STATUS_NO_DATA_DETECTED 0x8000001c
 #define NT_STATUS_STOPPED_ON_SYMLINK 0x8000002d
 #define NT_STATUS_DEVICE_REQUIRES_CLEANING 0x80000288
-#define NT_STATUS_DEVICE_DOOR_OPEN 0x80000288
+#define NT_STATUS_DEVICE_DOOR_OPEN 0x80000289
 #define NT_STATUS_UNSUCCESSFUL 0xC0000000 | 0x0001
 #define NT_STATUS_NOT_IMPLEMENTED 0xC0000000 | 0x0002
 #define NT_STATUS_INVALID_INFO_CLASS 0xC0000000 | 0x0003
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.1] smb/client: fix NT_STATUS_UNABLE_TO_FREE_VM value

[Sasha Levin]

From: ChenXiaoSong <chenxiaosong@kylinos.cn>

[ Upstream commit 9f99caa8950a76f560a90074e3a4b93cfa8b3d84 ]

This was reported by the KUnit tests in the later patches.

See MS-ERREF 2.3.1 STATUS_UNABLE_TO_FREE_VM. Keep it consistent with the
value in the documentation.

Signed-off-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of smb/client: fix NT_STATUS_UNABLE_TO_FREE_VM value

### 1. COMMIT MESSAGE ANALYSIS

The commit explicitly states it's a "fix" for an incorrect NT status
code value. Key points:
- Found by KUnit tests (systematic testing uncovered the issue)
- References MS-ERREF 2.3.1 documentation as the authoritative source
- Acked by Paulo Alcantara (Red Hat) - a key SMB/CIFS maintainer
- Committed by Steve French - the SMB subsystem maintainer

### 2. CODE CHANGE ANALYSIS

The change is a single-line modification in `fs/smb/client/nterr.h`:

```c
-#define NT_STATUS_UNABLE_TO_FREE_VM 0x80000000 | 0x001a
+#define NT_STATUS_UNABLE_TO_FREE_VM 0xC0000000 | 0x001a
```

In NT status codes, the high bits encode severity:
- `0x00000000` = Success
- `0x40000000` = Informational
- `0x80000000` = Warning
- `0xC0000000` = Error

The bug: `NT_STATUS_UNABLE_TO_FREE_VM` was incorrectly defined as a
"Warning" (`0x80000000`) instead of "Error" (`0xC0000000`). Looking at
the context, **all surrounding status codes** use `0xC0000000`, making
this one obvious outlier.

Per Microsoft's MS-ERREF documentation, STATUS_UNABLE_TO_FREE_VM
(0xC000001A) is indeed an error status, not a warning.

### 3. CLASSIFICATION

- **Bug type:** Incorrect constant value (data bug)
- **Not a feature:** Simply corrects an existing definition to match
  specification
- **Not a security issue:** Though incorrect error handling could have
  unexpected effects

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** 1
- **Files touched:** 1 (header file)
- **Complexity:** Minimal - single character change (`8` → `C`)
- **Risk:** Essentially zero - corrects an obvious typo/error to match:
  1. The official Microsoft documentation
  2. The pattern used by all surrounding definitions

### 5. USER IMPACT

If an SMB server returns this status code, the client would fail to
properly match and handle it due to the incorrect value. This could
cause:
- Failure to recognize error conditions
- Incorrect error messages to users
- Potential mishandling of this error scenario

While this specific status code may be rarely encountered in practice,
when it does occur, the current code would misbehave.

### 6. STABILITY INDICATORS

- **Reviewed by maintainers:** Acked by Paulo Alcantara, committed by
  Steve French
- **Testing:** Found through KUnit tests (automated testing)
- **Pattern consistency:** All other NT_STATUS_* codes in the same
  numerical range use `0xC0000000`

### 7. DEPENDENCY CHECK

This is a completely standalone fix. The header file has existed for a
long time, and this is just correcting an incorrect value within it. No
dependencies on other commits.

---

### Summary

**Should this be backported?**

This commit is an excellent backport candidate:

1. **Obviously correct:** The fix makes the value match both official
   Microsoft documentation and the pattern used by all surrounding
   definitions
2. **Fixes a real bug:** Incorrect status code would cause mismatched
   error handling
3. **Minimal scope:** One-character change in a single header file
4. **Zero regression risk:** This is purely a correctness fix to a
   constant
5. **No new features:** Just corrects existing code
6. **No dependencies:** Standalone fix
7. **Well-reviewed:** Acked by key SMB maintainer

This is exactly the type of safe, surgical, low-risk fix that stable
trees should include. The change is so minimal and so obviously correct
that there's essentially no risk, while the benefit is ensuring correct
SMB protocol handling.

**YES**

 fs/smb/client/nterr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/smb/client/nterr.h b/fs/smb/client/nterr.h
index 180602c22355e..e3a607b45e719 100644
--- a/fs/smb/client/nterr.h
+++ b/fs/smb/client/nterr.h
@@ -70,7 +70,7 @@ extern const struct nt_err_code_struct nt_errs[];
 #define NT_STATUS_NO_MEMORY 0xC0000000 | 0x0017
 #define NT_STATUS_CONFLICTING_ADDRESSES 0xC0000000 | 0x0018
 #define NT_STATUS_NOT_MAPPED_VIEW 0xC0000000 | 0x0019
-#define NT_STATUS_UNABLE_TO_FREE_VM 0x80000000 | 0x001a
+#define NT_STATUS_UNABLE_TO_FREE_VM 0xC0000000 | 0x001a
 #define NT_STATUS_UNABLE_TO_DELETE_SECTION 0xC0000000 | 0x001b
 #define NT_STATUS_INVALID_SYSTEM_SERVICE 0xC0000000 | 0x001c
 #define NT_STATUS_ILLEGAL_INSTRUCTION 0xC0000000 | 0x001d
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] drm/amd/display: shrink struct members

[Sasha Levin]

From: Rosen Penev <rosenp@gmail.com>

[ Upstream commit 7329417fc9ac128729c3a092b006c8f1fd0d04a6 ]

On a 32-bit ARM system, the audio_decoder struct ends up being too large
for dp_retrain_link_dp_test.

link_dp_cts.c:157:1: error: the frame size of 1328 bytes is larger than
1280 bytes [-Werror=frame-larger-than=]

This is mitigated by shrinking the members of the struct and avoids
having to deal with dynamic allocation.

feed_back_divider is assigned but otherwise unused. Remove both.

pixel_repetition looks like it should be a bool since it's only ever
assigned to 1. But there are checks for 2 and 4. Reduce to uint8_t.

Remove ss_percentage_divider. Unused.

Shrink refresh_rate as it gets assigned to at most a 3 digit integer
value.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 3849efdc7888d537f09c3dcfaea4b3cd377a102e)
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: drm/amd/display: shrink struct members

### 1. COMMIT MESSAGE ANALYSIS

The commit addresses a **build failure** on 32-bit ARM systems:
```
link_dp_cts.c:157:1: error: the frame size of 1328 bytes is larger than
1280 bytes [-Werror=frame-larger-than=]
```

The fix shrinks struct members to reduce stack frame size. Key changes:
- Remove `feed_back_divider` (assigned but never read - write-only)
- Remove `ss_percentage_divider` (completely unused)
- Shrink `pixel_repetition` from `uint32_t` to `uint8_t` (only assigned
  1, checked for 2,4 - all fit in uint8_t)
- Shrink `refresh_rate` from `uint32_t` to `uint16_t` ("at most 3 digit
  integer")

The commit is already marked as "(cherry picked from commit
3849efdc7888...)" indicating it was deemed important for another tree.

### 2. CODE CHANGE ANALYSIS

**In `dce110_hwseq.c`:**
- Removes one assignment: `audio_output->pll_info.feed_back_divider =
  pipe_ctx->pll_settings.feedback_divider;`
- This was a write to an unused field - safe to remove

**In `audio_types.h`:**
- `struct audio_crtc_info`: Type changes and reordering for better
  packing
- `struct audio_pll_info`: Removes two unused fields, reorders remaining
  members

These are **internal kernel structures** used within the AMD display
driver - not part of any userspace ABI.

### 3. CLASSIFICATION

This is a **BUILD FIX** - one of the explicitly allowed exception
categories for stable trees. The `-Werror=frame-larger-than=` flag is
commonly enabled in kernel builds, especially on embedded/ARM systems,
and this causes a hard compilation failure.

### 4. SCOPE AND RISK ASSESSMENT

**Lines changed:** Small - 2 files, ~20 lines modified
**Subsystem:** AMD display driver (DCE110 hardware sequencer, audio
types)

**Risk factors:**
- Struct layout changes - LOW risk since these are internal driver
  structures
- Removing unused fields - VERY LOW risk (can't break what's not used)
- Type narrowing (uint32_t → uint16_t/uint8_t) - LOW risk as values
  confirmed to fit

**Risk mitigation:**
- Reviewed by Alex Hung (AMD developer)
- Signed off by Alex Deucher (AMD display maintainer)
- Already cherry-picked to another tree

### 5. USER IMPACT

- **Affected users:** Anyone building Linux kernel on 32-bit ARM systems
  with AMD display support
- **Severity:** Build fails completely - users cannot compile the kernel
- **Scope:** Primarily embedded ARM systems running AMD GPUs

### 6. STABILITY INDICATORS

- `Reviewed-by: Alex Hung <alex.hung@amd.com>` ✓
- `Signed-off-by: Alex Deucher <alexander.deucher@amd.com>` (maintainer)
  ✓
- Already cherry-picked (deemed important) ✓

### 7. DEPENDENCY CHECK

The commit is self-contained. It only removes unused code and shrinks
types - no dependencies on other commits. The affected code (AMD
display, DCE110 HWSEQ, audio_types.h) exists in stable trees.

### Summary

**Pros:**
- Fixes a real build failure (compile error, not just warning)
- Build fixes are explicitly allowed in stable rules
- Small, contained changes
- Removes unused/dead code (lowest risk category)
- Type changes are provably safe (values fit)
- Reviewed and signed-off by AMD maintainers
- Already cherry-picked

**Cons:**
- Struct layout changes require careful consideration
- Only affects 32-bit ARM with specific kernel config

### Verdict

This is a legitimate **build fix** - one of the explicit exceptions in
stable kernel rules. The changes are low-risk: removing unused struct
members and narrowing types to values that demonstrably fit. The build
error affects real users on 32-bit ARM platforms. The fix has been
properly reviewed by AMD maintainers and already cherry-picked,
indicating it's deemed important. The risk of runtime regression is
minimal since unused code is being removed.

**YES**

 .../drm/amd/display/dc/hwss/dce110/dce110_hwseq.c    |  3 ---
 drivers/gpu/drm/amd/display/include/audio_types.h    | 12 +++++-------
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
index ebc220b29d142..b94fec8347400 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
@@ -1458,9 +1458,6 @@ void build_audio_output(
 						state->clk_mgr);
 	}
 
-	audio_output->pll_info.feed_back_divider =
-			pipe_ctx->pll_settings.feedback_divider;
-
 	audio_output->pll_info.dto_source =
 		translate_to_dto_source(
 			pipe_ctx->stream_res.tg->inst + 1);
diff --git a/drivers/gpu/drm/amd/display/include/audio_types.h b/drivers/gpu/drm/amd/display/include/audio_types.h
index e4a26143f14c9..6699ad4fa825e 100644
--- a/drivers/gpu/drm/amd/display/include/audio_types.h
+++ b/drivers/gpu/drm/amd/display/include/audio_types.h
@@ -47,15 +47,15 @@ struct audio_crtc_info {
 	uint32_t h_total;
 	uint32_t h_active;
 	uint32_t v_active;
-	uint32_t pixel_repetition;
 	uint32_t requested_pixel_clock_100Hz; /* in 100Hz */
 	uint32_t calculated_pixel_clock_100Hz; /* in 100Hz */
-	uint32_t refresh_rate;
+	uint32_t dsc_bits_per_pixel;
+	uint32_t dsc_num_slices;
 	enum dc_color_depth color_depth;
 	enum dc_pixel_encoding pixel_encoding;
+	uint16_t refresh_rate;
+	uint8_t pixel_repetition;
 	bool interlaced;
-	uint32_t dsc_bits_per_pixel;
-	uint32_t dsc_num_slices;
 };
 struct azalia_clock_info {
 	uint32_t pixel_clock_in_10khz;
@@ -78,11 +78,9 @@ enum audio_dto_source {
 
 struct audio_pll_info {
 	uint32_t audio_dto_source_clock_in_khz;
-	uint32_t feed_back_divider;
+	uint32_t ss_percentage;
 	enum audio_dto_source dto_source;
 	bool ss_enabled;
-	uint32_t ss_percentage;
-	uint32_t ss_percentage_divider;
 };
 
 struct audio_channel_associate_info {
-- 
2.51.0