[PATCH AUTOSEL 6.18-6.12] drm/amd/display: extend delta clamping logic to CM3 LUT helper

[PATCH AUTOSEL 6.18-6.12] drm/amd/display: extend delta clamping logic to CM3 LUT helper

[Sasha Levin]

From: Melissa Wen <mwen@igalia.com>

[ Upstream commit d25b32aa829a3ed5570138e541a71fb7805faec3 ]

Commit 27fc10d1095f ("drm/amd/display: Fix the delta clamping for shaper
LUT") fixed banding when using plane shaper LUT in DCN10 CM helper.  The
problem is also present in DCN30 CM helper, fix banding by extending the
same bug delta clamping fix to CM3.

Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 0274a54897f356f9c78767c4a2a5863f7dde90c6)
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit explicitly states it's extending a bug fix from DCN10 CM
helper to DCN30 CM helper. The referenced commit `27fc10d1095f`
("drm/amd/display: Fix the delta clamping for shaper LUT") fixed visual
banding artifacts when using plane shaper LUT. This commit applies the
same fix to the DCN30 (and DCN32, DCN401) code paths, which suffer from
the same banding problem.

### Code Change Analysis

Let me examine the actual changes in detail:

**1. Function signature change
(`cm3_helper_translate_curve_to_hw_format`)**:
- Adds `struct dc_context *ctx` as the first parameter
- This is needed to access `ctx->logger` for the `DC_LOG_ERROR` macro

**2. Core bug fix in `dcn30_cm_common.c`** (the important part):

The old code:
```c
rgb->delta_red_reg   = dc_fixpt_clamp_u0d10(rgb->delta_red);
rgb->delta_green_reg = dc_fixpt_clamp_u0d10(rgb->delta_green);
rgb->delta_blue_reg  = dc_fixpt_clamp_u0d10(rgb->delta_blue);
```

The new code:
```c
rgb->delta_red   = dc_fixpt_sub(rgb_plus_1->red,   rgb->red);
rgb->delta_green = dc_fixpt_sub(rgb_plus_1->green, rgb->green);
rgb->delta_blue  = dc_fixpt_sub(rgb_plus_1->blue,  rgb->blue);

red_clamp = dc_fixpt_clamp_u0d14(rgb->delta_red);
green_clamp = dc_fixpt_clamp_u0d14(rgb->delta_green);
blue_clamp = dc_fixpt_clamp_u0d14(rgb->delta_blue);

if (red_clamp >> 10 || green_clamp >> 10 || blue_clamp >> 10)
    DC_LOG_ERROR("Losing delta precision while programming shaper
LUT.");

rgb->delta_red_reg   = red_clamp & 0x3ff;
rgb->delta_green_reg = green_clamp & 0x3ff;
rgb->delta_blue_reg  = blue_clamp & 0x3ff;
```

The fix:
1. **Recalculates deltas** from the (potentially corrected) RGB values,
   rather than using stale delta values that may not account for the
   monotonicity corrections applied just above
2. **Clamps to u0d14** first (14-bit precision), then truncates to 10
   bits for the register, with a warning if precision is lost
3. The old code used `dc_fixpt_clamp_u0d10` directly which could produce
   incorrect delta values because the deltas weren't recalculated after
   the monotonicity fix

**3. All caller updates**: Every call site across dcn30, dcn32, and
dcn401 hwseq files is updated to pass the `ctx` parameter - purely
mechanical changes.

### Bug Classification

This is a **visual display bug fix** - banding artifacts when using
shaper LUT on DCN30+ hardware. Banding is a user-visible rendering
defect where smooth color gradients appear as discrete steps/bands
instead.

### Scope and Risk Assessment

**Scope**: The change touches 5 files across the AMD display subsystem:
- 1 core fix file (dcn30_cm_common.c)
- 1 header update (dcn30_cm_common.h)
- 3 caller update files (dcn30, dcn32, dcn401 hwseq)

**Risk concerns**:
1. **Function signature change**: This is an ABI-breaking change within
   the driver. All callers must be updated simultaneously. If any caller
   is missed in a backport, compilation will fail.
2. **Size**: The patch touches multiple files across multiple DCN
   generations. While the changes are logically simple, the breadth
   increases backport complexity.
3. **Dependency**: This commit depends on `27fc10d1095f`
   ("drm/amd/display: Fix the delta clamping for shaper LUT") being
   present for context, though the CM3 fix is self-contained.
4. **DCN401 code**: The dcn401 hwseq changes may not exist in older
   stable trees, requiring manual backport adjustments.

### Stable Kernel Criteria Assessment

- **Fixes a real bug**: Yes - visual banding artifacts on DCN30+ AMD
  GPUs
- **Obviously correct**: Yes - mirrors an already-accepted fix
  (27fc10d1095f) for DCN10
- **Small and contained**: Borderline - the core fix is small, but the
  function signature change propagates across many call sites
- **No new features**: Correct - this is purely a bug fix
- **Tested**: Has Reviewed-by from Harry Wentland (AMD display
  maintainer) and was cherry-picked

### Dependency Concerns

The commit was cherry-picked from mainline, suggesting it was already
selected for a stable-like branch. The function signature change means
this requires careful backporting - if the DCN401 files don't exist in
the target stable tree, those hunks need to be dropped. The prerequisite
commit `27fc10d1095f` should ideally be in the stable tree first (for
the DCN10 path), though the CM3 fix is technically independent.

### User Impact

AMD DCN30+ GPUs (RDNA 2 and later) are widely used in consumer desktops
and laptops. Banding in color gradients is a visible display quality
issue that affects all users of these GPUs when shaper LUTs are in use
(e.g., HDR content, color management workflows).

### Verdict

This fixes a real, user-visible display bug (banding) on widely-used AMD
GPU hardware. The fix is well-understood (same approach already applied
to DCN10), reviewed by the AMD display maintainer, and the core logic
change is small and correct. The main concern is the function signature
change requiring updates across multiple files, which increases backport
complexity but doesn't increase runtime risk - any missed caller would
result in a compilation error, not a silent bug. The fix is important
enough for display quality on modern AMD hardware that backporting is
warranted despite the moderate complexity.

**YES**

 .../amd/display/dc/dcn30/dcn30_cm_common.c    | 30 +++++++++++++++----
 .../display/dc/dwb/dcn30/dcn30_cm_common.h    |  2 +-
 .../amd/display/dc/hwss/dcn30/dcn30_hwseq.c   |  9 +++---
 .../amd/display/dc/hwss/dcn32/dcn32_hwseq.c   | 17 ++++++-----
 .../amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 16 +++++-----
 5 files changed, 49 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_cm_common.c b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_cm_common.c
index 0690c346f2c52..509626e6edcfd 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_cm_common.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_cm_common.c
@@ -105,9 +105,12 @@ void cm_helper_program_gamcor_xfer_func(
 #define NUMBER_REGIONS     32
 #define NUMBER_SW_SEGMENTS 16
 
-bool cm3_helper_translate_curve_to_hw_format(
-				const struct dc_transfer_func *output_tf,
-				struct pwl_params *lut_params, bool fixpoint)
+#define DC_LOGGER \
+		ctx->logger
+
+bool cm3_helper_translate_curve_to_hw_format(struct dc_context *ctx,
+					     const struct dc_transfer_func *output_tf,
+					     struct pwl_params *lut_params, bool fixpoint)
 {
 	struct curve_points3 *corner_points;
 	struct pwl_result_data *rgb_resulted;
@@ -248,6 +251,10 @@ bool cm3_helper_translate_curve_to_hw_format(
 	if (fixpoint == true) {
 		i = 1;
 		while (i != hw_points + 2) {
+			uint32_t red_clamp;
+			uint32_t green_clamp;
+			uint32_t blue_clamp;
+
 			if (i >= hw_points) {
 				if (dc_fixpt_lt(rgb_plus_1->red, rgb->red))
 					rgb_plus_1->red = dc_fixpt_add(rgb->red,
@@ -260,9 +267,20 @@ bool cm3_helper_translate_curve_to_hw_format(
 							rgb_minus_1->delta_blue);
 			}
 
-			rgb->delta_red_reg   = dc_fixpt_clamp_u0d10(rgb->delta_red);
-			rgb->delta_green_reg = dc_fixpt_clamp_u0d10(rgb->delta_green);
-			rgb->delta_blue_reg  = dc_fixpt_clamp_u0d10(rgb->delta_blue);
+			rgb->delta_red   = dc_fixpt_sub(rgb_plus_1->red,   rgb->red);
+			rgb->delta_green = dc_fixpt_sub(rgb_plus_1->green, rgb->green);
+			rgb->delta_blue  = dc_fixpt_sub(rgb_plus_1->blue,  rgb->blue);
+
+			red_clamp = dc_fixpt_clamp_u0d14(rgb->delta_red);
+			green_clamp = dc_fixpt_clamp_u0d14(rgb->delta_green);
+			blue_clamp = dc_fixpt_clamp_u0d14(rgb->delta_blue);
+
+			if (red_clamp >> 10 || green_clamp >> 10 || blue_clamp >> 10)
+				DC_LOG_ERROR("Losing delta precision while programming shaper LUT.");
+
+			rgb->delta_red_reg   = red_clamp & 0x3ff;
+			rgb->delta_green_reg = green_clamp & 0x3ff;
+			rgb->delta_blue_reg  = blue_clamp & 0x3ff;
 			rgb->red_reg         = dc_fixpt_clamp_u0d14(rgb->red);
 			rgb->green_reg       = dc_fixpt_clamp_u0d14(rgb->green);
 			rgb->blue_reg        = dc_fixpt_clamp_u0d14(rgb->blue);
diff --git a/drivers/gpu/drm/amd/display/dc/dwb/dcn30/dcn30_cm_common.h b/drivers/gpu/drm/amd/display/dc/dwb/dcn30/dcn30_cm_common.h
index b86347c9b0389..95f9318a54efc 100644
--- a/drivers/gpu/drm/amd/display/dc/dwb/dcn30/dcn30_cm_common.h
+++ b/drivers/gpu/drm/amd/display/dc/dwb/dcn30/dcn30_cm_common.h
@@ -59,7 +59,7 @@ void cm_helper_program_gamcor_xfer_func(
 	const struct pwl_params *params,
 	const struct dcn3_xfer_func_reg *reg);
 
-bool cm3_helper_translate_curve_to_hw_format(
+bool cm3_helper_translate_curve_to_hw_format(struct dc_context *ctx,
 	const struct dc_transfer_func *output_tf,
 	struct pwl_params *lut_params, bool fixpoint);
 
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn30/dcn30_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn30/dcn30_hwseq.c
index e47ed5571dfdd..731645a2ab9aa 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn30/dcn30_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn30/dcn30_hwseq.c
@@ -238,7 +238,7 @@ bool dcn30_set_blend_lut(
 	if (plane_state->blend_tf.type == TF_TYPE_HWPWL)
 		blend_lut = &plane_state->blend_tf.pwl;
 	else if (plane_state->blend_tf.type == TF_TYPE_DISTRIBUTED_POINTS) {
-		result = cm3_helper_translate_curve_to_hw_format(
+		result = cm3_helper_translate_curve_to_hw_format(plane_state->ctx,
 				&plane_state->blend_tf, &dpp_base->regamma_params, false);
 		if (!result)
 			return result;
@@ -333,8 +333,9 @@ bool dcn30_set_input_transfer_func(struct dc *dc,
 	if (plane_state->in_transfer_func.type == TF_TYPE_HWPWL)
 		params = &plane_state->in_transfer_func.pwl;
 	else if (plane_state->in_transfer_func.type == TF_TYPE_DISTRIBUTED_POINTS &&
-		cm3_helper_translate_curve_to_hw_format(&plane_state->in_transfer_func,
-				&dpp_base->degamma_params, false))
+		cm3_helper_translate_curve_to_hw_format(plane_state->ctx,
+							&plane_state->in_transfer_func,
+							&dpp_base->degamma_params, false))
 		params = &dpp_base->degamma_params;
 
 	result = dpp_base->funcs->dpp_program_gamcor_lut(dpp_base, params);
@@ -405,7 +406,7 @@ bool dcn30_set_output_transfer_func(struct dc *dc,
 				params = &stream->out_transfer_func.pwl;
 			else if (pipe_ctx->stream->out_transfer_func.type ==
 					TF_TYPE_DISTRIBUTED_POINTS &&
-					cm3_helper_translate_curve_to_hw_format(
+					cm3_helper_translate_curve_to_hw_format(stream->ctx,
 					&stream->out_transfer_func,
 					&mpc->blender_params, false))
 				params = &mpc->blender_params;
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
index f39292952702f..30bb5d8d85dc2 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
@@ -486,8 +486,9 @@ bool dcn32_set_mcm_luts(
 	if (plane_state->blend_tf.type == TF_TYPE_HWPWL)
 		lut_params = &plane_state->blend_tf.pwl;
 	else if (plane_state->blend_tf.type == TF_TYPE_DISTRIBUTED_POINTS) {
-		result = cm3_helper_translate_curve_to_hw_format(&plane_state->blend_tf,
-				&dpp_base->regamma_params, false);
+		result = cm3_helper_translate_curve_to_hw_format(plane_state->ctx,
+								 &plane_state->blend_tf,
+								 &dpp_base->regamma_params, false);
 		if (!result)
 			return result;
 
@@ -502,8 +503,9 @@ bool dcn32_set_mcm_luts(
 	else if (plane_state->in_shaper_func.type == TF_TYPE_DISTRIBUTED_POINTS) {
 		// TODO: dpp_base replace
 		ASSERT(false);
-		cm3_helper_translate_curve_to_hw_format(&plane_state->in_shaper_func,
-				&dpp_base->shaper_params, true);
+		cm3_helper_translate_curve_to_hw_format(plane_state->ctx,
+							&plane_state->in_shaper_func,
+							&dpp_base->shaper_params, true);
 		lut_params = &dpp_base->shaper_params;
 	}
 
@@ -543,8 +545,9 @@ bool dcn32_set_input_transfer_func(struct dc *dc,
 	if (plane_state->in_transfer_func.type == TF_TYPE_HWPWL)
 		params = &plane_state->in_transfer_func.pwl;
 	else if (plane_state->in_transfer_func.type == TF_TYPE_DISTRIBUTED_POINTS &&
-		cm3_helper_translate_curve_to_hw_format(&plane_state->in_transfer_func,
-				&dpp_base->degamma_params, false))
+		cm3_helper_translate_curve_to_hw_format(plane_state->ctx,
+							&plane_state->in_transfer_func,
+							&dpp_base->degamma_params, false))
 		params = &dpp_base->degamma_params;
 
 	dpp_base->funcs->dpp_program_gamcor_lut(dpp_base, params);
@@ -575,7 +578,7 @@ bool dcn32_set_output_transfer_func(struct dc *dc,
 				params = &stream->out_transfer_func.pwl;
 			else if (pipe_ctx->stream->out_transfer_func.type ==
 					TF_TYPE_DISTRIBUTED_POINTS &&
-					cm3_helper_translate_curve_to_hw_format(
+					cm3_helper_translate_curve_to_hw_format(stream->ctx,
 					&stream->out_transfer_func,
 					&mpc->blender_params, false))
 				params = &mpc->blender_params;
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
index 68e48a2492c9e..77cdd02a41bdd 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
@@ -427,7 +427,7 @@ void dcn401_populate_mcm_luts(struct dc *dc,
 		if (mcm_luts.lut1d_func->type == TF_TYPE_HWPWL)
 			m_lut_params.pwl = &mcm_luts.lut1d_func->pwl;
 		else if (mcm_luts.lut1d_func->type == TF_TYPE_DISTRIBUTED_POINTS) {
-			rval = cm3_helper_translate_curve_to_hw_format(
+			rval = cm3_helper_translate_curve_to_hw_format(mpc->ctx,
 					mcm_luts.lut1d_func,
 					&dpp_base->regamma_params, false);
 			m_lut_params.pwl = rval ? &dpp_base->regamma_params : NULL;
@@ -447,7 +447,7 @@ void dcn401_populate_mcm_luts(struct dc *dc,
 			m_lut_params.pwl = &mcm_luts.shaper->pwl;
 		else if (mcm_luts.shaper->type == TF_TYPE_DISTRIBUTED_POINTS) {
 			ASSERT(false);
-			rval = cm3_helper_translate_curve_to_hw_format(
+			rval = cm3_helper_translate_curve_to_hw_format(mpc->ctx,
 					mcm_luts.shaper,
 					&dpp_base->regamma_params, true);
 			m_lut_params.pwl = rval ? &dpp_base->regamma_params : NULL;
@@ -624,8 +624,9 @@ bool dcn401_set_mcm_luts(struct pipe_ctx *pipe_ctx,
 	if (plane_state->blend_tf.type == TF_TYPE_HWPWL)
 		lut_params = &plane_state->blend_tf.pwl;
 	else if (plane_state->blend_tf.type == TF_TYPE_DISTRIBUTED_POINTS) {
-		rval = cm3_helper_translate_curve_to_hw_format(&plane_state->blend_tf,
-				&dpp_base->regamma_params, false);
+		rval = cm3_helper_translate_curve_to_hw_format(plane_state->ctx,
+							       &plane_state->blend_tf,
+							       &dpp_base->regamma_params, false);
 		lut_params = rval ? &dpp_base->regamma_params : NULL;
 	}
 	result = mpc->funcs->program_1dlut(mpc, lut_params, mpcc_id);
@@ -636,8 +637,9 @@ bool dcn401_set_mcm_luts(struct pipe_ctx *pipe_ctx,
 		lut_params = &plane_state->in_shaper_func.pwl;
 	else if (plane_state->in_shaper_func.type == TF_TYPE_DISTRIBUTED_POINTS) {
 		// TODO: dpp_base replace
-		rval = cm3_helper_translate_curve_to_hw_format(&plane_state->in_shaper_func,
-				&dpp_base->shaper_params, true);
+		rval = cm3_helper_translate_curve_to_hw_format(plane_state->ctx,
+							       &plane_state->in_shaper_func,
+							       &dpp_base->shaper_params, true);
 		lut_params = rval ? &dpp_base->shaper_params : NULL;
 	}
 	result &= mpc->funcs->program_shaper(mpc, lut_params, mpcc_id);
@@ -671,7 +673,7 @@ bool dcn401_set_output_transfer_func(struct dc *dc,
 				params = &stream->out_transfer_func.pwl;
 			else if (pipe_ctx->stream->out_transfer_func.type ==
 					TF_TYPE_DISTRIBUTED_POINTS &&
-					cm3_helper_translate_curve_to_hw_format(
+					cm3_helper_translate_curve_to_hw_format(stream->ctx,
 					&stream->out_transfer_func,
 					&mpc->blender_params, false))
 				params = &mpc->blender_params;
-- 
2.51.0

[PATCH AUTOSEL 6.18] io_uring/fdinfo: be a bit nicer when looping a lot of SQEs/CQEs

[Sasha Levin]

From: Jens Axboe <axboe@kernel.dk>

[ Upstream commit 38cfdd9dd279473a73814df9fd7e6e716951d361 ]

Add cond_resched() in those dump loops, just in case a lot of entries
are being dumped. And detect invalid CQ ring head/tail entries, to avoid
iterating more than what is necessary. Generally not an issue, but can be
if things like KASAN or other debugging metrics are enabled.

Reported-by: 是参差 <shicenci@gmail.com>
Link: https://lore.kernel.org/all/PS1PPF7E1D7501FE5631002D242DD89403FAB9BA@PS1PPF7E1D7501F.apcprd02.prod.outlook.com/
Reviewed-by: Keith Busch <kbusch@kernel.org>
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 io_uring/fdinfo: cond_resched() and CQ bounds fix

### Commit Message Analysis

The commit addresses two issues in `io_uring/fdinfo.c`:

1. **Adding `cond_resched()` calls** in SQE/CQE dump loops to avoid
   holding the CPU for too long when dumping many entries, particularly
   with debugging tools like KASAN enabled.
2. **Detecting invalid CQ ring head/tail entries** to avoid iterating
   more than necessary — this bounds the CQE loop to `ctx->cq_entries`
   maximum iterations.

There's a `Reported-by:` tag indicating a real user hit this issue, and
a `Link:` to the mailing list discussion. The patch is `Reviewed-by:
Keith Busch` and authored by `Jens Axboe` (io_uring maintainer).

### Code Change Analysis

Let me examine the changes in detail:

**Change 1: `cond_resched()` in SQE loop** (line after `seq_printf(m,
"\n")` in the SQE loop)
- This is a straightforward addition to yield the CPU during potentially
  long loops. The SQE loop already had bounded iteration (`sq_entries`
  was calculated earlier), but with KASAN or heavy debugging, each
  iteration can be slow. This prevents soft lockups.

**Change 2: Bounded CQE loop**
- Old code: `while (cq_head < cq_tail)` — this depends on userspace-
  controlled `cq_head` and `cq_tail` values (read with `READ_ONCE`). If
  these values are corrupted or malicious, `cq_tail - cq_head` could be
  enormous (up to `UINT_MAX`), causing an extremely long loop.
- New code: `cq_entries = min(cq_tail - cq_head, ctx->cq_entries)` and
  `for (i = 0; i < cq_entries; i++)` — this bounds the iteration to at
  most `ctx->cq_entries`, which is the actual ring size. This is a
  defensive bounds check.
- Also adds `cond_resched()` in the CQE loop.

**Change 3: CQE32 accounting fix**
- When CQE32 is detected (`cqe32 = true`), both `cq_head` and `i` are
  incremented, properly accounting for the double-sized CQE entry in the
  bounded loop.

### Bug Classification

This fixes two real problems:

1. **Soft lockup / scheduling latency issue**: Without `cond_resched()`,
   dumping many SQEs/CQEs (especially with KASAN) can cause the kernel
   to not schedule for a long time, triggering soft lockup warnings or
   causing system unresponsiveness. This is a **real bug** — reported by
   a user.

2. **Unbounded loop from userspace-controlled values**: The original CQE
   loop was bounded only by `cq_tail - cq_head`, which are userspace-
   written values. While in the normal case these are reasonable,
   corrupted or malicious values could cause an extremely long
   (potentially billions of iterations) loop in kernel context. This is
   both a **robustness fix** and a **potential DoS vector** (any process
   can read `/proc/<pid>/fdinfo/<fd>` for its own io_uring fds,
   triggering this loop).

### Scope and Risk Assessment

- **Size**: Very small — ~10 lines changed in a single file
- **Subsystem**: io_uring fdinfo (diagnostic/debug path, not hot path)
- **Risk**: Extremely low
  - `cond_resched()` is a standard kernel practice in long loops — zero
    regression risk
  - Bounding the CQE loop to `ctx->cq_entries` is obviously correct —
    the ring can't have more entries than its size
  - The CQE32 `i++` accounting is straightforward
- **Dependencies**: None apparent — this is a self-contained change to a
  single function

### User Impact

- **Who is affected**: Anyone using io_uring who reads fdinfo
  (monitoring tools, debuggers, diagnostic scripts)
- **Severity**: Soft lockups and system unresponsiveness — moderate to
  high severity
- **Reproducibility**: Reported by a real user with a concrete scenario
  (KASAN-enabled kernel with many ring entries)

### Stability Indicators

- Written by Jens Axboe (io_uring maintainer)
- Reviewed by Keith Busch (known kernel developer)
- Small, obviously correct change
- Fixes a user-reported issue

### Conclusion

This commit fixes:
1. A real soft lockup / scheduling latency bug (cond_resched in loops)
2. A potential unbounded loop from userspace-controlled values (CQE
   bounds check)

Both are genuine bugs that affect real users. The fix is small,
obviously correct, self-contained, and carries virtually zero regression
risk. It meets all stable kernel criteria: it fixes a real bug, is small
and contained, is obviously correct, and doesn't introduce new features.

**YES**

 io_uring/fdinfo.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/io_uring/fdinfo.c b/io_uring/fdinfo.c
index 294c75a8a3bdb..3585ad8308504 100644
--- a/io_uring/fdinfo.c
+++ b/io_uring/fdinfo.c
@@ -65,7 +65,7 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
 	unsigned int cq_head = READ_ONCE(r->cq.head);
 	unsigned int cq_tail = READ_ONCE(r->cq.tail);
 	unsigned int sq_shift = 0;
-	unsigned int sq_entries;
+	unsigned int cq_entries, sq_entries;
 	int sq_pid = -1, sq_cpu = -1;
 	u64 sq_total_time = 0, sq_work_time = 0;
 	unsigned int i;
@@ -119,9 +119,11 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
 			}
 		}
 		seq_printf(m, "\n");
+		cond_resched();
 	}
 	seq_printf(m, "CQEs:\t%u\n", cq_tail - cq_head);
-	while (cq_head < cq_tail) {
+	cq_entries = min(cq_tail - cq_head, ctx->cq_entries);
+	for (i = 0; i < cq_entries; i++) {
 		struct io_uring_cqe *cqe;
 		bool cqe32 = false;
 
@@ -136,8 +138,11 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
 					cqe->big_cqe[0], cqe->big_cqe[1]);
 		seq_printf(m, "\n");
 		cq_head++;
-		if (cqe32)
+		if (cqe32) {
 			cq_head++;
+			i++;
+		}
+		cond_resched();
 	}
 
 	if (ctx->flags & IORING_SETUP_SQPOLL) {
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] ALSA: hda/realtek: Enable headset mic for Acer Nitro 5

[Sasha Levin]

From: Breno Baptista <brenomb07@gmail.com>

[ Upstream commit 51db05283f7c9c95a3e6853a3044cd04226551bf ]

Add quirk to support microphone input through headphone jack on Acer Nitro 5 AN515-57 (ALC295).

Signed-off-by: Breno Baptista <brenomb07@gmail.com>
Link: https://patch.msgid.link/20260205024341.26694-1-brenomb07@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis: ALSA: hda/realtek: Enable headset mic for Acer Nitro 5

### Commit Message Analysis

This commit adds a hardware quirk entry (`SND_PCI_QUIRK`) for the Acer
Nitro 5 AN515-57 laptop to enable headset microphone input through the
headphone jack. The codec is ALC295, and the fixup applied is
`ALC2XX_FIXUP_HEADSET_MIC`.

### Code Change Analysis

The change is a **single line addition** in the `alc269_fixup_tbl[]`
quirk table:

```c
SND_PCI_QUIRK(0x1025, 0x1539, "Acer Nitro 5 AN515-57",
ALC2XX_FIXUP_HEADSET_MIC),
```

- **Vendor ID 0x1025** = Acer
- **Subsystem ID 0x1539** = Acer Nitro 5 AN515-57
- **Fixup: ALC2XX_FIXUP_HEADSET_MIC** = an existing, well-tested fixup
  already used by similar Acer Nitro models

The entry is inserted in the correct sorted position (between 0x1534 and
0x159c), and notably, the adjacent entries for Acer Nitro 5 AN515-58
(0x159c) and AN517-55 (0x1597) already use the exact same
`ALC2XX_FIXUP_HEADSET_MIC` fixup. This is simply extending an existing
working quirk to another model in the same product family.

### Classification

This is a **hardware quirk addition** — one of the explicitly allowed
exception categories for stable backports. It:

1. Fixes a real user-facing problem: the headset microphone doesn't work
   without this quirk on the Acer Nitro 5 AN515-57
2. Uses an existing, proven fixup mechanism (`ALC2XX_FIXUP_HEADSET_MIC`)
3. Only affects the specific hardware identified by the PCI subsystem ID
4. Has zero risk of regression for any other hardware

### Scope and Risk Assessment

- **Lines changed**: 1 (addition only)
- **Files changed**: 1
- **Risk**: Essentially zero — the quirk is matched by PCI
  vendor/subsystem ID and only applies to the specific Acer laptop model
- **Subsystem maturity**: The HDA Realtek quirk table is one of the most
  stable and well-understood mechanisms in the kernel; hundreds of
  similar entries exist

### User Impact

Without this quirk, users of the Acer Nitro 5 AN515-57 cannot use the
headset microphone through the headphone jack. This is a common laptop
(gaming line) and headset mic support is essential for many users
(calls, gaming, etc.). The commit was submitted by an end user (Breno
Baptista) who presumably experienced the problem.

### Stability Indicators

- Accepted by Takashi Iwai (ALSA maintainer)
- Follows the exact same pattern as dozens of other quirk entries in the
  same table
- The same fixup (`ALC2XX_FIXUP_HEADSET_MIC`) is already proven on
  sibling models (AN515-58, AN517-55)

### Dependencies

None. This is a self-contained single-line quirk table entry addition.
The `ALC2XX_FIXUP_HEADSET_MIC` fixup and the quirk infrastructure
already exist in all stable trees that support this driver.

### Conclusion

This is a textbook example of a hardware quirk addition that belongs in
stable trees. It's a single-line addition to an existing quirk table,
using an already-proven fixup, fixing a real hardware issue (non-
functional headset mic) on a specific laptop model, with zero risk to
any other hardware or code path.

**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 9097de7d2e3d7..7604851d53b2f 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6238,6 +6238,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x1025, 0x1430, "Acer TravelMate B311R-31", ALC256_FIXUP_ACER_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1025, 0x1466, "Acer Aspire A515-56", ALC255_FIXUP_ACER_HEADPHONE_AND_MIC),
 	SND_PCI_QUIRK(0x1025, 0x1534, "Acer Predator PH315-54", ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1025, 0x1539, "Acer Nitro 5 AN515-57", ALC2XX_FIXUP_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1025, 0x159c, "Acer Nitro 5 AN515-58", ALC2XX_FIXUP_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1025, 0x169a, "Acer Swift SFG16", ALC256_FIXUP_ACER_SFG16_MICMUTE_LED),
 	SND_PCI_QUIRK(0x1025, 0x1826, "Acer Helios ZPC", ALC287_FIXUP_PREDATOR_SPK_CS35L41_I2C_2),
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] platform/x86: classmate-laptop: Add missing NULL pointer checks

[Sasha Levin]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

[ Upstream commit fe747d7112283f47169e9c16e751179a9b38611e ]

In a few places in the Classmate laptop driver, code using the accel
object may run before that object's address is stored in the driver
data of the input device using it.

For example, cmpc_accel_sensitivity_store_v4() is the "show" method
of cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(),
before calling dev_set_drvdata() for inputdev->dev.  If the sysfs
attribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev)
call in in cmpc_accel_sensitivity_store_v4() returns NULL which
leads to a NULL pointer dereference going forward.

Moreover, sysfs attributes using the input device are added before
initializing that device by cmpc_add_acpi_notify_device() and if one
of them is accessed before running that function, a NULL pointer
dereference will occur.

For example, cmpc_accel_sensitivity_attr_v4 is added before calling
cmpc_add_acpi_notify_device() and if it is read prematurely, the
dev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4()
returns NULL which leads to a NULL pointer dereference going forward.

Fix this by adding NULL pointer checks in all of the relevant places.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/12825381.O9o76ZdvQC@rafael.j.wysocki
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit message clearly describes a **NULL pointer dereference** bug
in the classmate-laptop driver. The author (Rafael J. Wysocki, a
prominent kernel maintainer) explains the race condition:

1. Sysfs attributes are registered **before** `dev_set_drvdata()` is
   called to store the accel object pointer
2. Sysfs attributes are also registered **before**
   `cmpc_add_acpi_notify_device()` initializes the input device
3. If userspace accesses these sysfs attributes in the window between
   creation and initialization, `dev_get_drvdata()` returns NULL,
   leading to a NULL pointer dereference (kernel oops/crash)

### Code Change Analysis

The fix is straightforward and mechanical - it adds NULL pointer checks
after `dev_get_drvdata()` calls in the following functions:

**V4 accelerometer functions:**
- `cmpc_accel_sensitivity_show_v4()` - 2 NULL checks added
- `cmpc_accel_sensitivity_store_v4()` - 2 NULL checks added
- `cmpc_accel_g_select_show_v4()` - 2 NULL checks added
- `cmpc_accel_g_select_store_v4()` - 2 NULL checks added
- `cmpc_accel_open_v4()` - 1 NULL check added

**Non-v4 accelerometer functions:**
- `cmpc_accel_sensitivity_show()` - 2 NULL checks added
- `cmpc_accel_sensitivity_store()` - 2 NULL checks added

Each check follows the same pattern:
```c
inputdev = dev_get_drvdata(&acpi->dev);
if (!inputdev)
    return -ENXIO;

accel = dev_get_drvdata(&inputdev->dev);
if (!accel)
    return -ENXIO;
```

This is the standard defensive pattern for sysfs callbacks that may be
called during device initialization/teardown.

### Bug Classification

- **Type**: NULL pointer dereference (race between sysfs attribute
  creation and device initialization)
- **Trigger**: Userspace reading/writing sysfs attributes during device
  probe
- **Consequence**: Kernel oops/crash
- **Severity**: Medium-High (crash from userspace access)

### Stable Kernel Criteria Assessment

1. **Obviously correct and tested**: Yes - simple NULL checks with
   appropriate error returns (-ENXIO). Reviewed by Ilpo Järvinen. The
   pattern is standard kernel defensive programming.
2. **Fixes a real bug**: Yes - NULL pointer dereference that causes a
   kernel crash.
3. **Important issue**: Yes - kernel crash triggered from userspace
   sysfs access.
4. **Small and contained**: Yes - single file, only adds NULL checks. No
   behavioral changes beyond preventing the crash.
5. **No new features/APIs**: Correct - purely defensive checks.
6. **Clean application**: Should apply cleanly to any stable tree that
   has this driver, as the changes are simple additions.

### Risk Assessment

- **Risk**: Very low. The changes only add early-return paths with
  -ENXIO when pointers are NULL. This cannot cause regressions - if the
  pointer was previously non-NULL, the check is a no-op. If it was NULL,
  we now return an error instead of crashing.
- **Scope**: Single file, single driver (classmate-laptop), well-
  contained.
- **Author credibility**: Rafael J. Wysocki is a top-level kernel
  maintainer (PM subsystem, ACPI), highly trustworthy.

### User Impact

The classmate-laptop driver serves Intel Classmate PC hardware
(educational laptops). While the user base may be small, the fix
prevents a kernel crash from a realistic race condition during device
initialization. Any system with this hardware could hit this during
boot.

### Conclusion

This is a textbook stable backport candidate:
- Fixes NULL pointer dereferences (kernel crashes)
- Small, surgical, obviously correct
- Single file, no dependencies
- No new features or behavioral changes
- Written and reviewed by senior kernel developers
- Zero regression risk

**YES**

 drivers/platform/x86/classmate-laptop.c | 32 +++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/platform/x86/classmate-laptop.c b/drivers/platform/x86/classmate-laptop.c
index 6b1b8e444e241..74d3eb83f56a6 100644
--- a/drivers/platform/x86/classmate-laptop.c
+++ b/drivers/platform/x86/classmate-laptop.c
@@ -207,7 +207,12 @@ static ssize_t cmpc_accel_sensitivity_show_v4(struct device *dev,
 
 	acpi = to_acpi_device(dev);
 	inputdev = dev_get_drvdata(&acpi->dev);
+	if (!inputdev)
+		return -ENXIO;
+
 	accel = dev_get_drvdata(&inputdev->dev);
+	if (!accel)
+		return -ENXIO;
 
 	return sysfs_emit(buf, "%d\n", accel->sensitivity);
 }
@@ -224,7 +229,12 @@ static ssize_t cmpc_accel_sensitivity_store_v4(struct device *dev,
 
 	acpi = to_acpi_device(dev);
 	inputdev = dev_get_drvdata(&acpi->dev);
+	if (!inputdev)
+		return -ENXIO;
+
 	accel = dev_get_drvdata(&inputdev->dev);
+	if (!accel)
+		return -ENXIO;
 
 	r = kstrtoul(buf, 0, &sensitivity);
 	if (r)
@@ -256,7 +266,12 @@ static ssize_t cmpc_accel_g_select_show_v4(struct device *dev,
 
 	acpi = to_acpi_device(dev);
 	inputdev = dev_get_drvdata(&acpi->dev);
+	if (!inputdev)
+		return -ENXIO;
+
 	accel = dev_get_drvdata(&inputdev->dev);
+	if (!accel)
+		return -ENXIO;
 
 	return sysfs_emit(buf, "%d\n", accel->g_select);
 }
@@ -273,7 +288,12 @@ static ssize_t cmpc_accel_g_select_store_v4(struct device *dev,
 
 	acpi = to_acpi_device(dev);
 	inputdev = dev_get_drvdata(&acpi->dev);
+	if (!inputdev)
+		return -ENXIO;
+
 	accel = dev_get_drvdata(&inputdev->dev);
+	if (!accel)
+		return -ENXIO;
 
 	r = kstrtoul(buf, 0, &g_select);
 	if (r)
@@ -302,6 +322,8 @@ static int cmpc_accel_open_v4(struct input_dev *input)
 
 	acpi = to_acpi_device(input->dev.parent);
 	accel = dev_get_drvdata(&input->dev);
+	if (!accel)
+		return -ENXIO;
 
 	cmpc_accel_set_sensitivity_v4(acpi->handle, accel->sensitivity);
 	cmpc_accel_set_g_select_v4(acpi->handle, accel->g_select);
@@ -549,7 +571,12 @@ static ssize_t cmpc_accel_sensitivity_show(struct device *dev,
 
 	acpi = to_acpi_device(dev);
 	inputdev = dev_get_drvdata(&acpi->dev);
+	if (!inputdev)
+		return -ENXIO;
+
 	accel = dev_get_drvdata(&inputdev->dev);
+	if (!accel)
+		return -ENXIO;
 
 	return sysfs_emit(buf, "%d\n", accel->sensitivity);
 }
@@ -566,7 +593,12 @@ static ssize_t cmpc_accel_sensitivity_store(struct device *dev,
 
 	acpi = to_acpi_device(dev);
 	inputdev = dev_get_drvdata(&acpi->dev);
+	if (!inputdev)
+		return -ENXIO;
+
 	accel = dev_get_drvdata(&inputdev->dev);
+	if (!accel)
+		return -ENXIO;
 
 	r = kstrtoul(buf, 0, &sensitivity);
 	if (r)
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.6] platform/x86/amd/pmc: Add quirk for MECHREVO Wujie 15X Pro

[Sasha Levin]

From: gongqi <550230171hxy@gmail.com>

[ Upstream commit 2b4e00d8e70ca8736fda82447be6a4e323c6d1f5 ]

The MECHREVO Wujie 15X Pro suffers from spurious IRQ issues related to
the AMD PMC. Add it to the quirk list to use the spurious_8042 fix.

Signed-off-by: gongqi <550230171hxy@gmail.com>
Link: https://patch.msgid.link/20260122155501.376199-4-550230171hxy@gmail.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit adds a DMI-based hardware quirk for the MECHREVO Wujie 15X
Pro laptop to the AMD PMC quirk list. The laptop suffers from **spurious
IRQ issues** related to the AMD PMC, and the fix applies the existing
`quirk_spurious_8042` workaround.

### Code Change Analysis

The change is a simple addition of a new DMI match entry to the
`fwbug_list[]` array:

```c
{
    .ident = "MECHREVO Wujie 15X Pro",
    .driver_data = &quirk_spurious_8042,
    .matches = {
        DMI_MATCH(DMI_BOARD_NAME, "WUJIE Series-X5SP4NAG"),
    }
},
```

This is **7 lines of new code** added to an existing quirk table. It
follows the exact same pattern as all the other entries in the table
(e.g., TUXEDO Stellaris, TUXEDO InfinityBook Pro, etc.). The quirk
mechanism (`quirk_spurious_8042`) already exists and is well-tested —
this commit simply adds another machine to the list of affected devices.

### Classification: Hardware Quirk

This falls squarely into the **"QUIRKS and WORKAROUNDS"** exception
category for stable backports:
- It's a hardware-specific quirk for a device with broken/buggy behavior
- It uses an existing, well-tested quirk mechanism
- It only affects the specific laptop model matched by DMI
- Without this quirk, the laptop experiences spurious IRQ issues which
  can cause problems during suspend/resume (a real user-facing bug)

### Scope and Risk Assessment

- **Lines changed**: 7 (addition only)
- **Files touched**: 1 (`pmc-quirks.c`)
- **Risk**: Essentially zero. The DMI match ensures this code only
  activates on the specific MECHREVO Wujie 15X Pro laptop. No other
  hardware is affected.
- **Dependencies**: None — the `quirk_spurious_8042` data structure and
  the quirk application mechanism already exist in stable trees.

### User Impact

- Users of the MECHREVO Wujie 15X Pro laptop experience spurious 8042
  IRQ issues related to the AMD PMC
- Without this quirk, the laptop likely has problems with suspend/resume
  functionality
- This is a real hardware issue affecting real users of this specific
  laptop model

### Stability Indicators

- The commit was reviewed and accepted by Ilpo Järvinen (Intel platform
  maintainer)
- It follows an established pattern with many identical entries in the
  same table
- The quirk mechanism is proven and used by multiple other laptops

### Conclusion

This is a textbook example of a hardware quirk addition that is
appropriate for stable backport. It's small, contained, zero-risk to
other hardware, fixes a real user-facing issue (spurious IRQs), and uses
an already-existing mechanism. The pattern is identical to dozens of
other quirk entries that regularly get backported.

**YES**

 drivers/platform/x86/amd/pmc/pmc-quirks.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/platform/x86/amd/pmc/pmc-quirks.c
index 404e62ad293a9..ed285afaf9b0d 100644
--- a/drivers/platform/x86/amd/pmc/pmc-quirks.c
+++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c
@@ -302,6 +302,13 @@ static const struct dmi_system_id fwbug_list[] = {
 			DMI_MATCH(DMI_BOARD_NAME, "XxKK4NAx_XxSP4NAx"),
 		}
 	},
+	{
+		.ident = "MECHREVO Wujie 15X Pro",
+		.driver_data = &quirk_spurious_8042,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_NAME, "WUJIE Series-X5SP4NAG"),
+		}
+	},
 	{}
 };
 
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.6] ASoC: amd: yc: Add quirk for HP 200 G2a 16

[Sasha Levin]

From: Dirk Su <dirk.su@canonical.com>

[ Upstream commit 611c7d2262d5645118e0b3a9a88475d35a8366f2 ]

Fix the missing mic on HP 200 G2a 16 by adding quirk with the
board ID 8EE4

Signed-off-by: Dirk Su <dirk.su@canonical.com>
Link: https://patch.msgid.link/20260129065038.39349-1-dirk.su@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis
The commit explicitly states it fixes a missing microphone on the HP 200
G2a 16 laptop by adding a DMI quirk entry with board ID "8EE4". This is
a straightforward hardware quirk addition.

### Code Change Analysis
The change adds exactly one new DMI table entry to the
`yc_acp_quirk_table[]` array in `sound/soc/amd/yc/acp6x-mach.c`:

```c
{
    .driver_data = &acp6x_card,
    .matches = {
        DMI_MATCH(DMI_BOARD_VENDOR, "HP"),
        DMI_MATCH(DMI_BOARD_NAME, "8EE4"),
    },
},
```

This is identical in structure to dozens of other entries already in the
table. It simply tells the AMD Yellow Carp audio driver to match this
specific HP board so the audio card is properly configured.

### Classification
This falls squarely into the **hardware quirk/workaround** exception
category. It:
- Adds a DMI match entry to an existing driver's quirk table
- Follows the exact same pattern as all other entries in the table
- Fixes a real hardware issue (non-functional microphone) for a specific
  laptop model
- Introduces zero risk of regression to any other hardware

### Scope and Risk Assessment
- **Lines changed**: ~7 lines (one table entry addition)
- **Files touched**: 1
- **Risk**: Essentially zero. The DMI match only triggers on the
  specific HP board with ID "8EE4". No other systems are affected.
- **Complexity**: Trivial — copy-paste of an existing pattern

### User Impact
Without this quirk, users of the HP 200 G2a 16 laptop have a non-
functional microphone. This is a real usability problem — the microphone
simply doesn't work. This is the kind of fix that stable users need:
their hardware doesn't work, and a tiny patch makes it work.

### Stability and Dependencies
- No dependencies on other commits
- The AMD YC audio driver and the quirk table infrastructure exist in
  all recent stable trees
- The patch applies cleanly as a simple table entry addition
- The author is from Canonical (Ubuntu), suggesting this was found and
  tested on real user hardware

### Precedent
This file (`acp6x-mach.c`) has had many similar quirk additions
backported to stable trees. This is routine stable material.

The fix is a trivial, zero-risk hardware quirk addition that fixes a
non-functional microphone on a specific HP laptop model. It perfectly
matches the stable kernel criteria for hardware quirks/workarounds.

**YES**

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

diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index c0a8afb42e165..3018e1a6f6f31 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -626,6 +626,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
 			DMI_MATCH(DMI_BOARD_NAME, "8BD6"),
 		}
 	},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "HP"),
+			DMI_MATCH(DMI_BOARD_NAME, "8EE4"),
+		}
+	},
 	{
 		.driver_data = &acp6x_card,
 		.matches = {
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.15] platform/x86: panasonic-laptop: Fix sysfs group leak in error path

[Sasha Levin]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

[ Upstream commit 43b0b7eff4b3fb684f257d5a24376782e9663465 ]

The acpi_pcc_hotkey_add() error path leaks sysfs group pcc_attr_group
if platform_device_register_simple() fails for the "panasonic" platform
device.

Address this by making it call sysfs_remove_group() in that case for
the group in question.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/3398370.44csPzL39Z@rafael.j.wysocki
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit message is clear and precise: it identifies a **sysfs group
leak** in the error path of `acpi_pcc_hotkey_add()`. Specifically, when
`platform_device_register_simple()` fails, the code jumps to
`out_backlight`, which skips the `sysfs_remove_group()` cleanup for
`pcc_attr_group` that was successfully created earlier. This is a
classic resource leak on an error path.

The author is Rafael J. Wysocki, a highly respected kernel maintainer
(PM subsystem, ACPI), and the patch is reviewed by Ilpo Järvinen (Intel
platform/x86 maintainer). Both are strong trust indicators.

### Code Change Analysis

The fix is extremely small and surgical — exactly 3 lines changed:

1. **Changed `goto out_backlight` to `goto out_sysfs`** — When
   `platform_device_register_simple()` fails, instead of jumping past
   the sysfs cleanup, it now jumps to a new label that properly removes
   the sysfs group first.

2. **Added new `out_sysfs:` label** with
   `sysfs_remove_group(&device->dev.kobj, &pcc_attr_group)` — This
   ensures the sysfs group created by `sysfs_create_group()` a few lines
   earlier is properly cleaned up.

The error path ordering is now correct:
- `out_platform` → unregister platform device
- `out_sysfs` → remove sysfs group (NEW)
- `out_backlight` → unregister backlight
- `out_input` → unregister input device
- `out_sinf` → free sinf
- `out_hotkey` → free pcc

This follows the standard reverse-order cleanup pattern in Linux kernel
drivers.

### Bug Classification

This is a **resource leak fix** on an error path. The leaked sysfs group
means:
- Sysfs entries remain dangling after driver probe failure
- Memory associated with the sysfs group attributes is leaked
- Could cause issues if the driver is retried or another driver tries to
  use the same sysfs paths

### Scope and Risk Assessment

- **Lines changed**: ~3 effective lines (one goto target change, two new
  lines for the label and cleanup call)
- **Files touched**: 1 (drivers/platform/x86/panasonic-laptop.c)
- **Risk**: Extremely low — this only affects the error path when
  `platform_device_register_simple()` fails. It cannot affect the normal
  (successful) code path at all.
- **Correctness**: Obviously correct — it follows the standard cleanup
  ordering pattern used everywhere in the kernel.

### Stable Kernel Criteria

1. **Obviously correct and tested**: Yes — trivial fix, reviewed by
   subsystem maintainer
2. **Fixes a real bug**: Yes — resource leak in error path
3. **Important issue**: Moderate — resource leak in driver probe error
   path. While not a crash, it's a correctness issue
4. **Small and contained**: Yes — 3 lines in one file
5. **No new features**: Correct — pure bug fix
6. **Clean backport**: The code should be straightforward to backport as
   this driver has been stable for a long time

### User Impact

This affects Panasonic laptop users. While the error path is not
frequently hit (it requires `platform_device_register_simple()` to fail,
which is uncommon), when it does occur, resources are leaked. The fix is
zero-risk to the normal path and trivially correct.

### Conclusion

This is a textbook stable-worthy fix: a small, obvious resource leak fix
in an error path, written by a top kernel maintainer, reviewed by the
subsystem maintainer, with zero risk of regression. It meets all stable
kernel criteria.

**YES**

 drivers/platform/x86/panasonic-laptop.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/panasonic-laptop.c b/drivers/platform/x86/panasonic-laptop.c
index 255317e6fec88..937f1a5b78edf 100644
--- a/drivers/platform/x86/panasonic-laptop.c
+++ b/drivers/platform/x86/panasonic-laptop.c
@@ -1089,7 +1089,7 @@ static int acpi_pcc_hotkey_add(struct acpi_device *device)
 			PLATFORM_DEVID_NONE, NULL, 0);
 		if (IS_ERR(pcc->platform)) {
 			result = PTR_ERR(pcc->platform);
-			goto out_backlight;
+			goto out_sysfs;
 		}
 		result = device_create_file(&pcc->platform->dev,
 			&dev_attr_cdpower);
@@ -1105,6 +1105,8 @@ static int acpi_pcc_hotkey_add(struct acpi_device *device)
 
 out_platform:
 	platform_device_unregister(pcc->platform);
+out_sysfs:
+	sysfs_remove_group(&device->dev.kobj, &pcc_attr_group);
 out_backlight:
 	backlight_device_unregister(pcc->backlight);
 out_input:
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.15] ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()

[Sasha Levin]

From: Ziyi Guo <n7l8m4@u.northwestern.edu>

[ Upstream commit f514248727606b9087bc38a284ff686e0093abf1 ]

fsl_xcvr_activate_ctl() has
lockdep_assert_held(&card->snd_card->controls_rwsem),
but fsl_xcvr_mode_put() calls it without acquiring this lock.

Other callers of fsl_xcvr_activate_ctl() in fsl_xcvr_startup() and
fsl_xcvr_shutdown() properly acquire the lock with down_read()/up_read().

Add the missing down_read()/up_read() calls around fsl_xcvr_activate_ctl()
in fsl_xcvr_mode_put() to fix the lockdep assertion and prevent potential
race conditions when multiple userspace threads access the control.

Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu>
Link: https://patch.msgid.link/20260202174112.2018402-1-n7l8m4@u.northwestern.edu
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Line 194 confirms the `lockdep_assert_held` — this will trigger a
lockdep warning when `fsl_xcvr_mode_put()` is called without the lock
held.

The function modifies `kctl->vd[0].access` (lines 205-207) and calls
`snd_ctl_notify` — without the lock, concurrent access could corrupt the
control's access flags, leading to undefined behavior.

### 3. Classification

- **Bug type**: Missing locking — race condition and lockdep assertion
  violation
- **Category**: Synchronization fix
- **This is NOT**: A feature, refactoring, or cleanup — it's purely
  adding missing synchronization

### 4. Scope and Risk Assessment

- **Lines changed**: +3 (down_read, up_read, blank line)
- **Files changed**: 1 (sound/soc/fsl/fsl_xcvr.c)
- **Risk**: Extremely low — the fix follows the exact same pattern as
  all other callers of the same function
- **Could it break anything?**: The lock is a read-lock (`down_read`),
  and `fsl_xcvr_mode_put()` is called from the ALSA control put path
  which should not hold this lock already (no deadlock risk). The other
  callers also use `down_read`, so there's no write-lock contention
  introduced.

### 5. User Impact

- **Who is affected**: Users of NXP i.MX SoCs with XCVR (audio
  transceiver) — this is used on i.MX 8MP and similar
- **Trigger**: Changing the audio mode via ALSA controls (e.g.,
  switching between SPDIF/ARC/eARC modes)
- **Symptom**: lockdep WARNING at minimum; potential data race on
  control access flags that could cause inconsistent state
- **Severity**: Medium — lockdep warnings are real bugs that indicate
  potential for corruption

### 6. Stability and Dependencies

- **Reviewed-by**: Accepted by Mark Brown (ASoC maintainer) — strong
  confidence signal
- **Dependencies**: None — this is a standalone fix. The
  `controls_rwsem` and `fsl_xcvr_activate_ctl()` function have been
  present for a long time
- **Backport difficulty**: Trivial — the patch is small and the
  surrounding code is stable

### 7. Summary

This is a textbook stable backport candidate:
- **Obviously correct**: Follows the exact same locking pattern as the 2
  other callers of the same function
- **Fixes a real bug**: Missing lock causes lockdep assertion and
  potential race condition
- **Small and contained**: 3 lines added in 1 file
- **No new features**: Pure bug fix
- **Low risk**: Read-lock addition following established pattern,
  accepted by subsystem maintainer

**YES**

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

diff --git a/sound/soc/fsl/fsl_xcvr.c b/sound/soc/fsl/fsl_xcvr.c
index 58db4906a01d5..51669e5fe8888 100644
--- a/sound/soc/fsl/fsl_xcvr.c
+++ b/sound/soc/fsl/fsl_xcvr.c
@@ -223,10 +223,13 @@ static int fsl_xcvr_mode_put(struct snd_kcontrol *kcontrol,
 
 	xcvr->mode = snd_soc_enum_item_to_val(e, item[0]);
 
+	down_read(&card->snd_card->controls_rwsem);
 	fsl_xcvr_activate_ctl(dai, fsl_xcvr_arc_mode_kctl.name,
 			      (xcvr->mode == FSL_XCVR_MODE_ARC));
 	fsl_xcvr_activate_ctl(dai, fsl_xcvr_earc_capds_kctl.name,
 			      (xcvr->mode == FSL_XCVR_MODE_EARC));
+	up_read(&card->snd_card->controls_rwsem);
+
 	/* Allow playback for SPDIF only */
 	rtd = snd_soc_get_pcm_runtime(card, card->dai_link);
 	rtd->pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream_count =
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow

[Sasha Levin]

From: Deepanshu Kartikey <kartikey406@gmail.com>

[ Upstream commit daafcc0ef0b358d9d622b6e3b7c43767aa3814ee ]

The dma_map_sg tracepoint can trigger a perf buffer overflow when
tracing large scatter-gather lists. With devices like virtio-gpu
creating large DRM buffers, nents can exceed 1000 entries, resulting
in:

  phys_addrs: 1000 * 8 bytes = 8,000 bytes
  dma_addrs:  1000 * 8 bytes = 8,000 bytes
  lengths:    1000 * 4 bytes = 4,000 bytes
  Total: ~20,000 bytes

This exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing:

  WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405
  perf buffer not large enough, wanted 24620, have 8192

Cap all three dynamic arrays at 128 entries using min() in the array
size calculation. This ensures arrays are only as large as needed
(up to the cap), avoiding unnecessary memory allocation for small
operations while preventing overflow for large ones.

The tracepoint now records the full nents/ents counts and a truncated
flag so users can see when data has been capped.

Changes in v2:
- Use min(nents, DMA_TRACE_MAX_ENTRIES) for dynamic array sizing
  instead of fixed DMA_TRACE_MAX_ENTRIES allocation (feedback from
  Steven Rostedt)
- This allocates only what's needed up to the cap, avoiding waste
  for small operations

Reported-by: syzbot+28cea38c382fd15e751a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=28cea38c382fd15e751a
Tested-by: syzbot+28cea38c382fd15e751a@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
Reviwed-by: Sean Anderson <sean.anderson@linux.dev>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20260130155215.69737-1-kartikey406@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This confirms the bug. At line 405, `WARN_ONCE` fires when `size >
PERF_MAX_TRACE_SIZE` (8192 bytes), and the function returns NULL,
causing the tracepoint to fail. The original `dma_map_sg` tracepoint
uses unbounded dynamic arrays (`__dynamic_array(u64, phys_addrs,
nents)`) which with large scatter-gather lists (nents > ~340 for a
single array of u64, or combined arrays > 8192 bytes total) will exceed
this limit.

### 3. CLASSIFICATION

**This is a clear bug fix.** It fixes:
1. A **buffer overflow** (trace data exceeding `PERF_MAX_TRACE_SIZE`)
2. A **kernel WARNING** triggered at runtime
3. A **functional failure** — the tracepoint becomes non-functional when
   the warning fires (returns NULL)

The bug is **syzbot-reported and reproducible**, with a concrete trigger
(virtio-gpu creating large DRM buffers).

### 4. SCOPE AND RISK ASSESSMENT

**Scope:**
- Single file changed: `include/trace/events/dma.h`
- Only the `dma_map_sg` TRACE_EVENT definition is modified
- Changes are contained within the tracepoint macro infrastructure

**Changes made:**
1. Define `DMA_TRACE_MAX_ENTRIES` (128) — a reasonable cap
2. Cap `__dynamic_array` sizes with `min(nents, DMA_TRACE_MAX_ENTRIES)`
3. Cap the `for_each_sg` iteration to traced_nents/traced_ents
4. Add `full_nents`, `full_ents`, and `truncated` fields for
   observability
5. Update `TP_printk` to show actual vs capped counts and a
   `[TRUNCATED]` marker

**Risk:**
- LOW risk. The change only affects the tracing subsystem, not the DMA
  mapping itself.
- The DMA operations proceed identically — only the trace output
  changes.
- Worst case: trace data is truncated (by design), but users are clearly
  informed via the `[TRUNCATED]` flag.
- The new fields (`full_nents`, `full_ents`, `truncated`) do change the
  tracepoint ABI slightly, but tracepoint ABIs are explicitly not stable
  (they can change between kernel versions).

### 5. USER IMPACT

- **Who is affected**: Anyone tracing DMA operations with perf on
  systems that create large scatter-gather lists (virtio-gpu, any GPU
  driver with large DRM buffers, potentially NVMe or other high-
  throughput I/O drivers).
- **Severity without fix**: Kernel WARNING on every affected tracepoint
  hit, plus the trace data is lost entirely (perf_trace_buf_alloc
  returns NULL). The WARNING can also trigger panic-on-warn
  configurations.
- **With the fix**: Trace data is properly capped and recorded, no
  WARNING.

### 6. STABILITY INDICATORS

- Reported by syzbot with a reproducer
- Tested by syzbot (confirmed fix)
- Reviewed by Sean Anderson
- Accepted by DMA subsystem maintainer Marek Szyprowski
- Iterated based on Steven Rostedt (tracing maintainer) feedback
- V2 of the patch — showing refinement

### 7. DEPENDENCY CHECK

- The `dma_map_sg` tracepoint was introduced in v6.12 (commit
  038eb433dc147). This fix only applies to 6.12+ stable trees.
- The patch modifies only the existing tracepoint definition and is
  self-contained.
- No dependencies on other patches.

### 8. CONCERNS

- **Note about `dma_alloc_sgt` and `dma_free_sgt` and other similar
  tracepoints**: These also have unbounded `__dynamic_array` based on
  `sgt->orig_nents` but are NOT fixed in this commit. This could mean
  those are less commonly hit or a separate fix is needed. However, this
  doesn't diminish the value of fixing the `dma_map_sg` case.
- **ABI change to tracepoint format**: The tracepoint output format
  changes (new fields added, format modified). While tracepoint ABIs are
  not considered stable, any perf scripts parsing the exact format of
  `dma_map_sg` would need updating. This is minor since tracepoint
  formats are expected to change.
- The patch should apply cleanly to 6.12.y since the file hasn't had
  many changes in this area since v6.12.

### SUMMARY

This is a well-crafted, syzbot-reported, tested-and-reviewed fix for a
real buffer overflow in the DMA tracing subsystem. The bug causes kernel
WARNINGs and complete failure of DMA scatter-gather tracing with large
buffers. The fix is small, contained to a single file, affects only the
tracing path (not actual DMA operations), and is low-risk. It has strong
trust indicators: syzbot-tested, maintainer-reviewed, and iterated based
on subsystem maintainer feedback. The only limitation is that it applies
only to stable trees 6.12+ where the tracepoint exists.

**YES**

 include/trace/events/dma.h | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/include/trace/events/dma.h b/include/trace/events/dma.h
index b3fef140ae155..33e99e792f1aa 100644
--- a/include/trace/events/dma.h
+++ b/include/trace/events/dma.h
@@ -275,6 +275,8 @@ TRACE_EVENT(dma_free_sgt,
 				sizeof(u64), sizeof(u64)))
 );
 
+#define DMA_TRACE_MAX_ENTRIES 128
+
 TRACE_EVENT(dma_map_sg,
 	TP_PROTO(struct device *dev, struct scatterlist *sgl, int nents,
 		 int ents, enum dma_data_direction dir, unsigned long attrs),
@@ -282,9 +284,12 @@ TRACE_EVENT(dma_map_sg,
 
 	TP_STRUCT__entry(
 		__string(device, dev_name(dev))
-		__dynamic_array(u64, phys_addrs, nents)
-		__dynamic_array(u64, dma_addrs, ents)
-		__dynamic_array(unsigned int, lengths, ents)
+		__field(int, full_nents)
+		__field(int, full_ents)
+		__field(bool, truncated)
+		__dynamic_array(u64, phys_addrs,  min(nents, DMA_TRACE_MAX_ENTRIES))
+		__dynamic_array(u64, dma_addrs, min(ents, DMA_TRACE_MAX_ENTRIES))
+		__dynamic_array(unsigned int, lengths, min(ents, DMA_TRACE_MAX_ENTRIES))
 		__field(enum dma_data_direction, dir)
 		__field(unsigned long, attrs)
 	),
@@ -292,11 +297,16 @@ TRACE_EVENT(dma_map_sg,
 	TP_fast_assign(
 		struct scatterlist *sg;
 		int i;
+		int traced_nents = min_t(int, nents, DMA_TRACE_MAX_ENTRIES);
+		int traced_ents = min_t(int, ents, DMA_TRACE_MAX_ENTRIES);
 
 		__assign_str(device);
-		for_each_sg(sgl, sg, nents, i)
+		__entry->full_nents = nents;
+		__entry->full_ents = ents;
+		__entry->truncated = (nents > DMA_TRACE_MAX_ENTRIES) || (ents > DMA_TRACE_MAX_ENTRIES);
+		for_each_sg(sgl, sg, traced_nents, i)
 			((u64 *)__get_dynamic_array(phys_addrs))[i] = sg_phys(sg);
-		for_each_sg(sgl, sg, ents, i) {
+		for_each_sg(sgl, sg, traced_ents, i) {
 			((u64 *)__get_dynamic_array(dma_addrs))[i] =
 				sg_dma_address(sg);
 			((unsigned int *)__get_dynamic_array(lengths))[i] =
@@ -306,9 +316,12 @@ TRACE_EVENT(dma_map_sg,
 		__entry->attrs = attrs;
 	),
 
-	TP_printk("%s dir=%s dma_addrs=%s sizes=%s phys_addrs=%s attrs=%s",
+	TP_printk("%s dir=%s nents=%d/%d ents=%d/%d%s dma_addrs=%s sizes=%s phys_addrs=%s attrs=%s",
 		__get_str(device),
 		decode_dma_data_direction(__entry->dir),
+		min_t(int, __entry->full_nents, DMA_TRACE_MAX_ENTRIES), __entry->full_nents,
+		min_t(int, __entry->full_ents, DMA_TRACE_MAX_ENTRIES), __entry->full_ents,
+		__entry->truncated ? " [TRUNCATED]" : "",
 		__print_array(__get_dynamic_array(dma_addrs),
 			      __get_dynamic_array_len(dma_addrs) /
 				sizeof(u64), sizeof(u64)),
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] drm/tegra: hdmi: sor: Fix error: variable ‘j’ set but not used

[Sasha Levin]

From: Brahmajit Das <listout@listout.xyz>

[ Upstream commit 1beee8d0c263b3e239c8d6616e4f8bb700bed658 ]

The variable j is set, however never used in or outside the loop, thus
resulting in dead code.
Building with GCC 16 results in a build error due to
-Werror=unused-but-set-variable= enabled by default.
This patch clean up the dead code and fixes the build error.

Example build log:
drivers/gpu/drm/tegra/sor.c:1867:19: error: variable ‘j’ set but not used [-Werror=unused-but-set-variable=]
 1867 |         size_t i, j;
      |                   ^

Signed-off-by: Brahmajit Das <listout@listout.xyz>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20250901212020.3757519-1-listout@listout.xyz
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of Commit: drm/tegra: hdmi: sor: Fix error: variable 'j' set
but not used

### 1. Commit Message Analysis

The commit message explicitly states this is a **build fix** for GCC 16,
which enables `-Werror=unused-but-set-variable=` by default. The commit
removes dead code (an unused variable `j`) to fix a compilation error.

Key indicators:
- "Fix error" - indicates a build failure
- "Building with GCC 16 results in a build error" - explicit mention of
  build breakage
- Provides concrete build log showing the error

### 2. Code Change Analysis

The changes are minimal and purely mechanical:

**In `drivers/gpu/drm/tegra/hdmi.c`:**
- Line 660: Changes `size_t i, j;` to `size_t i;`
- Line 693: Changes `for (i = 3, j = 0; i < size; i += 7, j += 8)` to
  `for (i = 3; i < size; i += 7)`

**In `drivers/gpu/drm/tegra/sor.c`:**
- Line 1866: Changes `size_t i, j;` to `size_t i;`
- Line 1899: Changes `for (i = 3, j = 0; i < size; i += 7, j += 8)` to
  `for (i = 3; i < size; i += 7)`

The variable `j` was:
1. Declared but never used anywhere
2. Incremented in the loop (`j += 8`) but the value was never read
3. Pure dead code that has no functional impact

### 3. Classification

This is a **build fix** - one of the explicit exception categories that
ARE allowed in stable:

> **BUILD FIXES:**
> - Fixes for compilation errors or warnings, Kconfig dependency fixes,
include file fixes
> - These are critical for users who need to build the kernel

### 4. Scope and Risk Assessment

- **Lines changed:** ~4 lines total (2 per file)
- **Files affected:** 2 files in the same subsystem (Tegra DRM driver)
- **Risk level:** Extremely low
- **Complexity:** None - purely removes unused code
- **Behavioral change:** None - the variable was never used

This is one of the lowest-risk changes possible:
- No logic changes
- No control flow changes
- No memory management changes
- Simply removing dead code that was never executed meaningfully

### 5. User Impact

**Who is affected:**
- Anyone trying to build the kernel with GCC 16
- Tegra (NVIDIA) platform users who need HDMI output

**Severity:**
- Without this fix, the kernel fails to compile with newer GCC versions
- This blocks users from building the kernel entirely

### 6. Stability Indicators

- Signed-off by the subsystem maintainer (Thierry Reding from NVIDIA)
- Link to the mailing list discussion provided
- The change is trivial and obviously correct

### 7. Dependency Check

- No dependencies on other commits
- The affected code (Tegra DRM HDMI/SOR drivers) exists in stable trees
- The fix is self-contained

### Conclusion

This commit meets all stable kernel criteria for a **build fix**:

1. **Obviously correct:** The variable `j` was declared, incremented,
   but never read - pure dead code
2. **Fixes a real bug:** Build failure with GCC 16
3. **Small and contained:** Only 4 lines changed across 2 related files
4. **No new features:** Removes unused code
5. **No risk of regression:** Cannot change behavior since the removed
   code was never used

Build fixes are explicitly allowed in stable trees because they are
critical for users who need to build the kernel. As GCC 16 becomes more
widely used (and is now the default compiler in some distributions),
this fix will become essential for anyone building the kernel.

The fix is trivial, obviously correct, and fixes a real build failure.
It has zero risk of causing runtime regressions since it only removes
dead code.

**YES**

 drivers/gpu/drm/tegra/hdmi.c | 4 ++--
 drivers/gpu/drm/tegra/sor.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 8cd2969e7d4bf..c4820f5e76581 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -658,7 +658,7 @@ static void tegra_hdmi_write_infopack(struct tegra_hdmi *hdmi, const void *data,
 {
 	const u8 *ptr = data;
 	unsigned long offset;
-	size_t i, j;
+	size_t i;
 	u32 value;
 
 	switch (ptr[0]) {
@@ -691,7 +691,7 @@ static void tegra_hdmi_write_infopack(struct tegra_hdmi *hdmi, const void *data,
 	 * - subpack_low: bytes 0 - 3
 	 * - subpack_high: bytes 4 - 6 (with byte 7 padded to 0x00)
 	 */
-	for (i = 3, j = 0; i < size; i += 7, j += 8) {
+	for (i = 3; i < size; i += 7) {
 		size_t rem = size - i, num = min_t(size_t, rem, 4);
 
 		value = tegra_hdmi_subpack(&ptr[i], num);
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 21f3dfdcc5c95..bc7dd562cf6b6 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -1864,7 +1864,7 @@ static void tegra_sor_hdmi_write_infopack(struct tegra_sor *sor,
 {
 	const u8 *ptr = data;
 	unsigned long offset;
-	size_t i, j;
+	size_t i;
 	u32 value;
 
 	switch (ptr[0]) {
@@ -1897,7 +1897,7 @@ static void tegra_sor_hdmi_write_infopack(struct tegra_sor *sor,
 	 * - subpack_low: bytes 0 - 3
 	 * - subpack_high: bytes 4 - 6 (with byte 7 padded to 0x00)
 	 */
-	for (i = 3, j = 0; i < size; i += 7, j += 8) {
+	for (i = 3; i < size; i += 7) {
 		size_t rem = size - i, num = min_t(size_t, rem, 4);
 
 		value = tegra_sor_hdmi_subpack(&ptr[i], num);
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.1] ASoC: Intel: sof_es8336: Add DMI quirk for Huawei BOD-WXX9

[Sasha Levin]

From: Tagir Garaev <tgaraev653@gmail.com>

[ Upstream commit 6b641122d31f9d33e7d60047ee0586d1659f3f54 ]

Add DMI entry for Huawei Matebook D (BOD-WXX9) with HEADPHONE_GPIO
and DMIC quirks.

This device has ES8336 codec with:
- GPIO 16 (headphone-enable) for headphone amplifier control
- GPIO 17 (speakers-enable) for speaker amplifier control
- GPIO 269 for jack detection IRQ
- 2-channel DMIC

Hardware investigation shows that both GPIO 16 and 17 are required
for proper audio routing, as headphones and speakers share the same
physical output (HPOL/HPOR) and are separated only via amplifier
enable signals.

RFC: Seeking advice on GPIO control issue:

GPIO values change in driver (gpiod_get_value() shows logical value
changes) but not physically (debugfs gpio shows no change). The same
gpiod_set_value_cansleep() calls work correctly in probe context with
msleep(), but fail when called from DAPM event callbacks.

Context information from diagnostics:
- in_atomic=0, in_interrupt=0, irqs_disabled=0
- Process context: pipewire
- GPIO 17 (speakers): changes in driver, no physical change
- GPIO 16 (headphone): changes in driver, no physical change

In Windows, audio switching works without visible GPIO changes,
suggesting possible ACPI/firmware involvement.

Any suggestions on how to properly control these GPIOs from DAPM
events would be appreciated.

Signed-off-by: Tagir Garaev <tgaraev653@gmail.com>
Link: https://patch.msgid.link/20260201121728.16597-1-tgaraev653@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of ASoC: Intel: sof_es8336: Add DMI quirk for Huawei BOD-
WXX9

### 1. Commit Message Analysis

The commit adds a DMI quirk entry for the Huawei Matebook D (BOD-WXX9)
laptop to the `sof_es8336` audio driver. The quirk enables
`SOF_ES8336_HEADPHONE_GPIO` and `SOF_ES8336_ENABLE_DMIC` flags for this
specific hardware.

Notably, the commit message contains an RFC section describing an
**unresolved GPIO control issue** - the GPIOs change logically but not
physically when called from DAPM event callbacks. This means the quirk
entry is being added, but the author acknowledges that audio switching
(headphone/speaker) may not fully work yet.

### 2. Code Change Analysis

The change is a pure **DMI quirk table addition**:
- Adds a single new entry to the `sof_es8336_quirk_table[]` array
- Matches `DMI_SYS_VENDOR = "HUAWEI"` and `DMI_PRODUCT_NAME = "BOD-
  WXX9"`
- Sets `SOF_ES8336_HEADPHONE_GPIO | SOF_ES8336_ENABLE_DMIC` as driver
  data
- No code logic changes, no new functions, no structural modifications

The pattern is identical to the existing HUAWEI entry (BOHB-WAX9-PCB-B2)
just below it, which uses `SOF_ES8336_HEADPHONE_GPIO |
SOC_ES8336_HEADSET_MIC1`.

### 3. Classification

This falls squarely into the **hardware quirk/workaround** exception
category for stable backports. DMI quirk entries for audio codecs are
one of the most common types of stable-appropriate additions. They:
- Enable audio functionality on specific hardware
- Are trivially small (data-only addition to an existing table)
- Cannot affect any other hardware (DMI matching is device-specific)
- Follow an established pattern already in the driver

### 4. Scope and Risk Assessment

- **Lines changed**: ~9 lines of new code (one table entry)
- **Files touched**: 1 file (`sound/soc/intel/boards/sof_es8336.c`)
- **Risk**: Extremely low - the DMI match ensures this code path only
  activates on the specific Huawei BOD-WXX9 laptop. No other systems are
  affected.
- **Regression potential**: Near zero for any system other than the
  target device.

### 5. User Impact

- **Who benefits**: Users of Huawei Matebook D (BOD-WXX9) laptops
  running Linux
- **Without this quirk**: The DMIC (internal microphone) and headphone
  GPIO configuration won't be properly set, potentially resulting in no
  audio or broken audio routing
- **Severity**: Audio not working is a significant usability issue for
  laptop users

### 6. Concerns

- The RFC section in the commit message is notable - the author reports
  that GPIO control from DAPM callbacks doesn't work as expected
  (physical GPIO state doesn't change). This suggests the quirk may
  provide partial functionality (DMIC works, but headphone/speaker
  switching may not work fully).
- However, even partial functionality (enabling DMIC) is better than no
  quirk entry at all.
- The commit was accepted by the subsystem maintainer (Mark Brown)
  despite the RFC, suggesting the base quirk entry is valid.

### 7. Dependency Check

No dependencies on other commits. The quirk flags
(`SOF_ES8336_HEADPHONE_GPIO`, `SOF_ES8336_ENABLE_DMIC`) and the quirk
table infrastructure already exist in stable trees where this driver is
present.

### 8. Stability Indicators

- Accepted via the standard ASoC maintainer path (Mark Brown)
- Follows the exact same pattern as existing entries in the same table
- Data-only change with zero logic modifications

### Decision

This is a textbook hardware quirk addition - a small, safe, data-only
change to an existing DMI quirk table that enables audio functionality
on a specific laptop model. It matches the "QUIRKS and WORKAROUNDS"
exception category perfectly. The risk is essentially zero (only affects
one specific hardware model), and the benefit is real (audio support for
Huawei Matebook D users on stable kernels).

**YES**

 sound/soc/intel/boards/sof_es8336.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/sound/soc/intel/boards/sof_es8336.c b/sound/soc/intel/boards/sof_es8336.c
index 09acd80d23e0f..cf50de5c2edd8 100644
--- a/sound/soc/intel/boards/sof_es8336.c
+++ b/sound/soc/intel/boards/sof_es8336.c
@@ -332,6 +332,15 @@ static int sof_es8336_quirk_cb(const struct dmi_system_id *id)
  * if the topology file is modified as well.
  */
 static const struct dmi_system_id sof_es8336_quirk_table[] = {
+	{
+		.callback = sof_es8336_quirk_cb,
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "BOD-WXX9"),
+		},
+		.driver_data = (void *)(SOF_ES8336_HEADPHONE_GPIO |
+					SOF_ES8336_ENABLE_DMIC)
+	},
 	{
 		.callback = sof_es8336_quirk_cb,
 		.matches = {
-- 
2.51.0

[PATCH AUTOSEL 6.18] ASoC: sof_sdw: Add a quirk for Lenovo laptop using sidecar amps with cs42l43

[Sasha Levin]

From: Maciej Strozek <mstrozek@opensource.cirrus.com>

[ Upstream commit 1425900231372acf870dd89e8d3bb4935f7f0c81 ]

Add a quirk for a Lenovo laptop (SSID: 0x17aa3821) to allow using sidecar
CS35L57 amps with CS42L43 codec.

Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260128092410.1540583-1-mstrozek@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis
This commit adds a hardware quirk (PCI SSID entry) for a specific Lenovo
laptop (SSID: 0x17aa3821) to enable sidecar CS35L57 amplifiers with the
CS42L43 codec. The commit message is straightforward and describes a
device-specific quirk addition.

### Code Change Analysis
The change is a **single line addition**:
```c
SND_PCI_QUIRK(0x17aa, 0x3821, "Lenovo 0x3821", SOC_SDW_SIDECAR_AMPS),
```

This adds an entry to the `sof_sdw_ssid_quirk_table[]` array, which is a
table of PCI subsystem ID quirks. The entry maps a specific Lenovo
laptop's subsystem ID (vendor 0x17aa, device 0x3821) to the
`SOC_SDW_SIDECAR_AMPS` quirk flag.

### Classification: Hardware Quirk / Device ID Addition

This falls squarely into the **QUIRKS and WORKAROUNDS** exception
category for stable backports:
- It's a hardware-specific quirk for a specific laptop model
- It uses an existing mechanism (`SND_PCI_QUIRK` macro,
  `sof_sdw_ssid_quirk_table`)
- It adds to an existing table with similar entries already present
- The quirk flag `SOC_SDW_SIDECAR_AMPS` already exists and is used by
  the driver

### Risk Assessment
- **Scope**: Single line, single file change
- **Risk**: Extremely low — only affects the specific Lenovo laptop with
  SSID 0x17aa:0x3821
- **Side effects**: None for any other hardware; the quirk is matched by
  PCI subsystem ID
- **Dependencies**: The `SOC_SDW_SIDECAR_AMPS` flag and the quirk
  infrastructure must exist in the stable tree

### User Impact
Without this quirk, owners of this specific Lenovo laptop would have
non-functional or incorrectly configured audio (the sidecar amplifiers
wouldn't be recognized/used). This is a real hardware enablement issue —
the laptop's speakers likely don't work properly without this quirk.

### Stability Indicators
- **Reviewed-by**: Cezary Rojewski (Intel audio maintainer)
- **Signed-off-by**: Mark Brown (ASoC subsystem maintainer)
- This is a well-understood, minimal pattern used extensively in audio
  drivers

### Concerns
- The `SOC_SDW_SIDECAR_AMPS` quirk flag must exist in the target stable
  tree. This flag and the cs42l43 sidecar amp support may be relatively
  new, so it may only apply to recent stable branches (e.g., 6.12.y or
  later). If the flag doesn't exist in older stable trees, the patch
  simply won't apply, which is safe.
- No other dependencies — this is a self-contained table entry addition.

### Verdict
This is a textbook stable-worthy hardware quirk addition: a single-line
entry in an existing quirk table, enabling audio hardware on a specific
laptop model. It has zero risk to other hardware, is reviewed by
subsystem maintainers, and fixes a real user-facing problem (broken
audio).

**YES**

 sound/soc/intel/boards/sof_sdw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/intel/boards/sof_sdw.c b/sound/soc/intel/boards/sof_sdw.c
index c013e31d098e7..198858b57d9f5 100644
--- a/sound/soc/intel/boards/sof_sdw.c
+++ b/sound/soc/intel/boards/sof_sdw.c
@@ -794,6 +794,7 @@ static const struct snd_pci_quirk sof_sdw_ssid_quirk_table[] = {
 	SND_PCI_QUIRK(0x17aa, 0x2347, "Lenovo P16", SOC_SDW_CODEC_MIC),
 	SND_PCI_QUIRK(0x17aa, 0x2348, "Lenovo P16", SOC_SDW_CODEC_MIC),
 	SND_PCI_QUIRK(0x17aa, 0x2349, "Lenovo P1", SOC_SDW_CODEC_MIC),
+	SND_PCI_QUIRK(0x17aa, 0x3821, "Lenovo 0x3821", SOC_SDW_SIDECAR_AMPS),
 	{}
 };
 
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] gpiolib: acpi: Fix gpio count with string references

[Sasha Levin]

From: Alban Bedel <alban.bedel@lht.dlh.de>

[ Upstream commit c62e0658d458d8f100445445c3ddb106f3824a45 ]

Since commit 9880702d123f2 ("ACPI: property: Support using strings in
reference properties") it is possible to use strings instead of local
references. This work fine with single GPIO but not with arrays as
acpi_gpio_package_count() didn't handle this case. Update it to handle
strings like local references to cover this case as well.

Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://patch.msgid.link/20260129145944.3372777-1-alban.bedel@lht.dlh.de
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The prerequisite commit appeared in v6.10+. So the bug affects stable
trees from 6.10 onward (6.10.y, 6.11.y, 6.12.y, etc.).

### 7. CONCLUSION

This commit:
- **Fixes a real bug**: GPIO array counting fails when ACPI firmware
  uses string references
- **Is obviously correct**: Adding a switch case for strings to match
  the same handling as local references
- **Is minimal**: One line addition
- **Has zero risk**: Cannot affect existing code paths; only enables a
  new case in a switch statement
- **Has been reviewed** by the ACPI/GPIO maintainer (Mika Westerberg)
  and merged by the GPIO maintainer (Bartosz Golaszewski)
- **Has a clear dependency**: Only applies to trees with commit
  `9880702d123f2` (v6.10+)
- **Fixes real hardware support**: Users with firmware using string
  references for GPIO arrays would have broken device functionality

This is a textbook stable backport candidate: small, surgical, correct,
and fixes real user-impacting functionality.

**YES**

 drivers/gpio/gpiolib-acpi-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpiolib-acpi-core.c b/drivers/gpio/gpiolib-acpi-core.c
index e64e21fd6bbaa..8110690ea69d0 100644
--- a/drivers/gpio/gpiolib-acpi-core.c
+++ b/drivers/gpio/gpiolib-acpi-core.c
@@ -1359,6 +1359,7 @@ static int acpi_gpio_package_count(const union acpi_object *obj)
 	while (element < end) {
 		switch (element->type) {
 		case ACPI_TYPE_LOCAL_REFERENCE:
+		case ACPI_TYPE_STRING:
 			element += 3;
 			fallthrough;
 		case ACPI_TYPE_INTEGER:
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.6] ASoC: cs42l43: Correct handling of 3-pole jack load detection

[Sasha Levin]

From: Charles Keepax <ckeepax@opensource.cirrus.com>

[ Upstream commit e77a4081d7e324dfa876a9560b2a78969446ba82 ]

The load detection process for 3-pole jacks requires slightly
updated reference values to ensure an accurate result. Update
the code to apply different tunings for the 3-pole and 4-pole
cases. This also updates the thresholds overall so update the
relevant comments to match.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260130150927.2964664-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The driver was added in August 2023 (likely kernel 6.6 or 6.7
timeframe), so it exists in recent stable trees.

### User Impact Assessment

- **Who is affected**: Users with CS42L43 audio codec hardware (Cirrus
  Logic codec, likely found in laptops/tablets)
- **Symptom**: Headphones could be misdetected as line-out, resulting in
  incorrect audio output behavior
- **Severity**: MEDIUM — not a crash, but audio malfunction that
  directly impacts user experience
- **Vendor fix**: From Cirrus Logic themselves, high confidence in
  correctness

### Risk vs. Benefit

- **Benefit**: Correct headphone/line-out detection for CS42L43 users,
  especially for 3-pole jacks
- **Risk**: Very low — codec-specific, vendor-provided values, only
  affects this hardware
- **Backport complexity**: The patch is self-contained;
  `regmap_multi_reg_write_bypassed()` already exists in stable trees

### Conclusion

This is a vendor-provided hardware tuning fix from Cirrus Logic that
corrects jack detection behavior on their CS42L43 codec. It fixes real-
world audio misdetection where headphones are wrongly classified as
line-out. The fix is contained to a single codec driver, uses existing
kernel APIs, and comes directly from the hardware vendor with
authoritative knowledge of the correct register values. It's analogous
to a hardware quirk — different tuning values needed for different jack
types.

The change is small, well-scoped, low-risk, and fixes a user-visible bug
(incorrect jack type detection).

**YES**

 sound/soc/codecs/cs42l43-jack.c | 37 +++++++++++++++++++++++++++------
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/sound/soc/codecs/cs42l43-jack.c b/sound/soc/codecs/cs42l43-jack.c
index 867e23d4fb8d8..744488f371ea4 100644
--- a/sound/soc/codecs/cs42l43-jack.c
+++ b/sound/soc/codecs/cs42l43-jack.c
@@ -496,7 +496,23 @@ void cs42l43_bias_sense_timeout(struct work_struct *work)
 	pm_runtime_put_autosuspend(priv->dev);
 }
 
-static void cs42l43_start_load_detect(struct cs42l43_codec *priv)
+static const struct reg_sequence cs42l43_3pole_patch[] = {
+	{ 0x4000,	0x00000055 },
+	{ 0x4000,	0x000000AA },
+	{ 0x17420,	0x8500F300 },
+	{ 0x17424,	0x36003E00 },
+	{ 0x4000,	0x00000000 },
+};
+
+static const struct reg_sequence cs42l43_4pole_patch[] = {
+	{ 0x4000,	0x00000055 },
+	{ 0x4000,	0x000000AA },
+	{ 0x17420,	0x7800E600 },
+	{ 0x17424,	0x36003800 },
+	{ 0x4000,	0x00000000 },
+};
+
+static void cs42l43_start_load_detect(struct cs42l43_codec *priv, bool mic)
 {
 	struct cs42l43 *cs42l43 = priv->core;
 
@@ -520,6 +536,15 @@ static void cs42l43_start_load_detect(struct cs42l43_codec *priv)
 			dev_err(priv->dev, "Load detect HP power down timed out\n");
 	}
 
+	if (mic)
+		regmap_multi_reg_write_bypassed(cs42l43->regmap,
+						cs42l43_4pole_patch,
+						ARRAY_SIZE(cs42l43_4pole_patch));
+	else
+		regmap_multi_reg_write_bypassed(cs42l43->regmap,
+						cs42l43_3pole_patch,
+						ARRAY_SIZE(cs42l43_3pole_patch));
+
 	regmap_update_bits(cs42l43->regmap, CS42L43_BLOCK_EN3,
 			   CS42L43_ADC1_EN_MASK | CS42L43_ADC2_EN_MASK, 0);
 	regmap_update_bits(cs42l43->regmap, CS42L43_DACCNFG2, CS42L43_HP_HPF_EN_MASK, 0);
@@ -598,7 +623,7 @@ static int cs42l43_run_load_detect(struct cs42l43_codec *priv, bool mic)
 
 	reinit_completion(&priv->load_detect);
 
-	cs42l43_start_load_detect(priv);
+	cs42l43_start_load_detect(priv, mic);
 	time_left = wait_for_completion_timeout(&priv->load_detect,
 						msecs_to_jiffies(CS42L43_LOAD_TIMEOUT_MS));
 	cs42l43_stop_load_detect(priv);
@@ -622,11 +647,11 @@ static int cs42l43_run_load_detect(struct cs42l43_codec *priv, bool mic)
 	}
 
 	switch (val & CS42L43_AMP3_RES_DET_MASK) {
-	case 0x0: // low impedance
-	case 0x1: // high impedance
+	case 0x0: // < 22 Ohm impedance
+	case 0x1: // < 150 Ohm impedance
+	case 0x2: // < 1000 Ohm impedance
 		return CS42L43_JACK_HEADPHONE;
-	case 0x2: // lineout
-	case 0x3: // Open circuit
+	case 0x3: // > 1000 Ohm impedance
 		return CS42L43_JACK_LINEOUT;
 	default:
 		return -EINVAL;
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] drm/amd/display: remove assert around dpp_base replacement

[Sasha Levin]

From: Melissa Wen <mwen@igalia.com>

[ Upstream commit 84962445cd8a83dc5bed4c8ad5bbb2c1cdb249a0 ]

There is nothing wrong if in_shaper_func type is DISTRIBUTED POINTS.
Remove the assert placed for a TODO to avoid misinterpretations.

Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1714dcc4c2c53e41190896eba263ed6328bcf415)
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

### Critical Finding

`ASSERT(false)` expands to `WARN_ON_ONCE(!(false))` which is
`WARN_ON_ONCE(true)`. This means **every time** this code path is hit on
a production kernel, it will generate a `WARN_ON_ONCE` — producing a
full stack trace in the kernel log and potentially triggering panic-on-
warn configurations.

This is a real bug for users who:
1. Have DCN 3.2 hardware (AMD display controllers)
2. Use color management features where `in_shaper_func.type ==
   TF_TYPE_DISTRIBUTED_POINTS`
3. Run kernels with `panic_on_warn=1` (some hardened configurations) —
   this would **crash** the system

### Classification

This is a **bug fix** — removing a false assertion that incorrectly
triggers a kernel warning on a valid code path. It's not a cleanup or
feature addition.

### Risk Assessment

- **Scope**: One line removal in a single file
- **Risk**: Essentially zero — removing a bogus `ASSERT(false)` cannot
  introduce regressions
- **Benefit**: Prevents spurious WARN_ON_ONCE on valid code paths;
  prevents crashes on panic-on-warn configurations
- **Subsystem**: AMD display driver (DCN 3.2) — widely used on modern
  AMD GPUs

### Stable Criteria Check

1. **Obviously correct and tested**: Yes — removing a known-false assert
   is obviously correct. Reviewed-by and cherry-picked.
2. **Fixes a real bug**: Yes — spurious WARN_ON triggering on a valid
   code path is a real bug.
3. **Important issue**: Moderate — causes kernel warnings and potential
   crashes on panic-on-warn systems.
4. **Small and contained**: Yes — single line removal.
5. **No new features**: Correct — no new functionality added.

**YES**

 drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
index 30bb5d8d85dc2..c6fde355ac823 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
@@ -502,7 +502,6 @@ bool dcn32_set_mcm_luts(
 		lut_params = &plane_state->in_shaper_func.pwl;
 	else if (plane_state->in_shaper_func.type == TF_TYPE_DISTRIBUTED_POINTS) {
 		// TODO: dpp_base replace
-		ASSERT(false);
 		cm3_helper_translate_curve_to_hw_format(plane_state->ctx,
 							&plane_state->in_shaper_func,
 							&dpp_base->shaper_params, true);
-- 
2.51.0