Archive-only list for patches
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: "Timur Kristóf" <timur.kristof@gmail.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Rodrigo Siqueira" <siqueira@igalia.com>,
	"Alex Hung" <alex.hung@amd.com>,
	"Sasha Levin" <sashal@kernel.org>
Subject: [PATCH AUTOSEL 6.16-5.10] drm/amd/display: Don't warn when missing DCE encoder caps
Date: Mon, 25 Aug 2025 08:14:57 -0400	[thread overview]
Message-ID: <20250825121505.2983941-8-sashal@kernel.org> (raw)
In-Reply-To: <20250825121505.2983941-1-sashal@kernel.org>

From: Timur Kristóf <timur.kristof@gmail.com>

[ Upstream commit 8246147f1fbaed522b8bcc02ca34e4260747dcfb ]

On some GPUs the VBIOS just doesn't have encoder caps,
or maybe not for every encoder.

This isn't really a problem and it's handled well,
so let's not litter the logs with it.

Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Rodrigo Siqueira <siqueira@igalia.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 33e0227ee96e62d034781e91f215e32fd0b1d512)
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my analysis of this commit, here is my determination:

**Backport Status: YES**

## Extensive Explanation:

This commit is a good candidate for backporting to stable kernel trees
for the following reasons:

### 1. **It fixes a user-visible issue (log spam)**
The commit addresses warning messages that unnecessarily clutter system
logs. The code shows that when `get_encoder_cap_info()` returns
`BP_RESULT_NORECORD` (meaning the VBIOS doesn't have encoder
capabilities for that specific encoder), it was incorrectly logging a
warning. Looking at the code pattern across the AMD display driver,
`BP_RESULT_NORECORD` is a normal, expected condition - not an error.

### 2. **The fix is minimal and contained**
The change is extremely simple - it only modifies the condition check
from:
```c
if (BP_RESULT_OK == result) {
    // handle success
} else {
    DC_LOG_WARNING(...); // Always warn on non-OK
}
```
to:
```c
if (result == BP_RESULT_OK) {
    // handle success
} else if (result != BP_RESULT_NORECORD) {
    DC_LOG_WARNING(...); // Only warn on actual errors
}
```

### 3. **No functional changes or new features**
The commit doesn't change any behavior - it only suppresses
inappropriate warning messages. The driver already handles the missing
encoder caps gracefully (as noted in the commit message: "This isn't
really a problem and it's handled well").

### 4. **Low risk of regression**
The change only affects logging behavior. It doesn't modify:
- Any hardware initialization sequences
- Any encoder capabilities detection logic
- Any functional paths in the driver
- Any data structures or APIs

### 5. **Pattern consistency across the codebase**
My grep analysis shows that `BP_RESULT_NORECORD` is commonly handled
without warnings in other parts of the AMD display driver. For example,
in `dc_link.c`, it uses `ASSERT(bp_result == BP_RESULT_NORECORD)`
showing it's an expected condition. Many other functions simply return
`BP_RESULT_NORECORD` without logging warnings.

### 6. **Applied to two identical code paths**
The commit applies the same fix to both
`dce110_link_encoder_construct()` and `dce60_link_encoder_construct()`
functions, maintaining consistency and preventing the warning in both
DCE 11.0 and DCE 6.0 hardware paths.

### 7. **Already cherry-picked**
The commit message shows "(cherry picked from commit 33e0227ee96e...)",
indicating it was already deemed important enough to cherry-pick to
another branch, suggesting its stability importance.

### 8. **Quality of Life improvement for users**
Reducing unnecessary log spam improves the user experience and makes it
easier to identify real problems in system logs. This is especially
important for users monitoring their systems for actual issues.

The commit follows stable tree rules perfectly: it's a small, contained
fix for a real issue (log spam) that affects users, with minimal risk of
introducing regressions.

 drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
index 4a9d07c31bc5..0c50fe266c8a 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
@@ -896,13 +896,13 @@ void dce110_link_encoder_construct(
 						enc110->base.id, &bp_cap_info);
 
 	/* Override features with DCE-specific values */
-	if (BP_RESULT_OK == result) {
+	if (result == BP_RESULT_OK) {
 		enc110->base.features.flags.bits.IS_HBR2_CAPABLE =
 				bp_cap_info.DP_HBR2_EN;
 		enc110->base.features.flags.bits.IS_HBR3_CAPABLE =
 				bp_cap_info.DP_HBR3_EN;
 		enc110->base.features.flags.bits.HDMI_6GB_EN = bp_cap_info.HDMI_6GB_EN;
-	} else {
+	} else if (result != BP_RESULT_NORECORD) {
 		DC_LOG_WARNING("%s: Failed to get encoder_cap_info from VBIOS with error code %d!\n",
 				__func__,
 				result);
@@ -1798,13 +1798,13 @@ void dce60_link_encoder_construct(
 						enc110->base.id, &bp_cap_info);
 
 	/* Override features with DCE-specific values */
-	if (BP_RESULT_OK == result) {
+	if (result == BP_RESULT_OK) {
 		enc110->base.features.flags.bits.IS_HBR2_CAPABLE =
 				bp_cap_info.DP_HBR2_EN;
 		enc110->base.features.flags.bits.IS_HBR3_CAPABLE =
 				bp_cap_info.DP_HBR3_EN;
 		enc110->base.features.flags.bits.HDMI_6GB_EN = bp_cap_info.HDMI_6GB_EN;
-	} else {
+	} else if (result != BP_RESULT_NORECORD) {
 		DC_LOG_WARNING("%s: Failed to get encoder_cap_info from VBIOS with error code %d!\n",
 				__func__,
 				result);
-- 
2.50.1


  parent reply	other threads:[~2025-08-25 12:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-25 12:14 [PATCH AUTOSEL 6.16-5.15] fs: writeback: fix use-after-free in __mark_inode_dirty() Sasha Levin
2025-08-25 12:14 ` [PATCH AUTOSEL 6.16-6.1] cdc_ncm: Flag Intel OEM version of Fibocom L850-GL as WWAN Sasha Levin
2025-08-25 12:14 ` [PATCH AUTOSEL 6.16-6.6] LoongArch: Save LBT before FPU in setup_sigcontext() Sasha Levin
2025-08-25 12:14 ` [PATCH AUTOSEL 6.16] btrfs: clear block dirty if submit_one_sector() failed Sasha Levin
2025-08-25 12:14 ` [PATCH AUTOSEL 6.16] platform/x86/amd: pmc: Drop SMU F/W match for Cezanne Sasha Levin
2025-08-25 12:14 ` [PATCH AUTOSEL 6.16] LoongArch: Add cpuhotplug hooks to fix high cpu usage of vCPU threads Sasha Levin
2025-08-25 12:14 ` [PATCH AUTOSEL 6.16-6.12] btrfs: zoned: skip ZONE FINISH of conventional zones Sasha Levin
2025-08-25 12:14 ` Sasha Levin [this message]
2025-08-25 12:14 ` [PATCH AUTOSEL 6.16-6.1] Bluetooth: hci_sync: Avoid adding default advertising on startup Sasha Levin
2025-08-25 12:14 ` [PATCH AUTOSEL 6.16-6.6] cpupower: Fix a bug where the -t option of the set subcommand was not working Sasha Levin
2025-08-25 12:15 ` [PATCH AUTOSEL 6.16-6.12] drm/rockchip: vop2: make vp registers nonvolatile Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250825121505.2983941-8-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=alex.hung@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=patches@lists.linux.dev \
    --cc=siqueira@igalia.com \
    --cc=stable@vger.kernel.org \
    --cc=timur.kristof@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox