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 &&

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_mqyrn6XXzso... [1] Signed-off-by: Krzysztof Kozlowski krzysztof.kozlowski@oss.qualcomm.com Link: https://patch.msgid.link/20251203141644.106459-2-krzysztof.kozlowski@oss.qua... 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))

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); }

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

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 {