linux.git/drivers/gpu/drm/amd/display/modules/hdcp, branch v7.2-rc2

drm/amd/display: guard against overflow in HDCP message dump

2026-07-01T17:00:40+00:00

[Why]
mod_hdcp_dump_binary_message() computed target_size (a uint32_t) as roughly
byte_size * msg_size and gated the whole write on buf_size >= target_size. A
large msg_size can overflow target_size, wrapping it to a small value that
passes the check while the loop still writes byte_size * msg_size bytes
into buf. All current callers pass small constants so this is not reachable
today, but the unchecked arithmetic should be hardened.

[How]
Drop the overflow-prone target_size precomputation and instead bounds-check the
output position on every iteration, stopping once the next entry would not leave
room for the trailing terminator. This cannot overflow and, for oversized
messages, dumps as much as fits rather than printing nothing.

Fixes: 4c283fdac08a ("drm/amd/display: Add HDCP module")
Assisted-by: Copilot:claude-opus-4.8
Reviewed-by: Alex Hung 
Signed-off-by: Harry Wentland 
Signed-off-by: George Zhang 
Signed-off-by: Alex Deucher 
(cherry picked from commit d0a775e5d70b376696245a14c09e3aa6dde0023a)
Cc: stable@vger.kernel.org

drm/amd/display: Update HDCP and info_packet modules for FRL

2026-06-03T17:44:49+00:00

The HDCP module has a minor update for FRL, and info_packet is
updated for ALLM.

Signed-off-by: Harry Wentland 
Reviewed-by: Fangzhi Zuo 
Tested-by: Dan Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size

2026-06-03T17:38:01+00:00

[Why & How]
During HDCP 2.x repeater authentication over HDMI, the driver reads the
sink's RxStatus register and extracts a 10-bit message size field (max
value 1023). This value is used as the read length for the ReceiverID
list without being clamped to the size of the destination buffer
rx_id_list[177]. A malicious HDMI repeater could advertise a message
size larger than the buffer, causing an out-of-bounds write during the
I2C read.

Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the
rx_id_list buffer, matching the approach already used in the DP branch.

Fixes: eff682f83c9c ("drm/amd/display: Add DDC handles for HDCP2.2")
Assisted-by: Copilot:claude-opus-4.6
Reviewed-by: Alex Hung 
Signed-off-by: Harry Wentland 
Signed-off-by: Ray Wu 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: Fix warnings

2026-05-11T20:10:34+00:00

[Why & How]
Fix various warnings related to unsigned/signed mismatches
-  Consistently use the same signedness for a given value
-  Explcitly cast between types when needed

Reviewed-by: Dillon Varone 
Signed-off-by: Clay King 
Signed-off-by: James Lin 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: Fix Silence warnings

2026-03-23T18:15:31+00:00

Also affects: freesync, hdcp, info_packet, power

[Why] Resolve compiler warnings by marking unused parameters explicitly.

[How] In .c/.h keep parameter names in signatures and add a line with
      `(void)param;`  inside the function body

Preserved function signatures and avoids breaking code paths that
may reference the parameter under conditional compilation.

Reviewed-by: Aric Cyr 
Signed-off-by: Gaghik Khachatrian 
Signed-off-by: Chuanyu Tseng 
Signed-off-by: Alex Deucher

drm/amd/display: Refactor HDCP Status Log Format

2025-11-12T02:54:16+00:00

Add missing part for
drm/amd/display: fw locality check refactors

Reviewed-by: Aurabindo Pillai 
Signed-off-by: Wenjing Liu 
Signed-off-by: Fangzhi Zuo 
Tested-by: Dan Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: add macros to simplify code

2025-11-12T02:53:26+00:00

[Why & How]
Adding macros to simplify the process of adding new error codes.
Currently, to add an error code, the developer needs to add both the
enum and the string translation. This is error prone and can lead to
inconsistencies. The refactor adds a macro to automatically add the
string translation based on the enum.

Reviewed-by: Aric Cyr 
Signed-off-by: Wenjing Liu 
Signed-off-by: Ray Wu 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: fw locality check refactors

2025-11-04T16:53:19+00:00

[why]
There are some new changes for HDCP2 firmware locality check. The
implementation doesn't perfectly fit the intended design and clarity.

1. Clarify and consolidate variable responsibilities.
The previous implementation introduced the following variables:
- config.ddc.funcs.atomic_write_poll_read_i2c (optional pointer)
- hdcp->config.ddc.funcs.atomic_write_poll_read_aux (optional pointer)
- hdcp->connection.link.adjust.hdcp2.force_sw_locality_check (bool)
- hdcp->config.debug.lc_enable_sw_fallback (bool)
- use_fw (bool)
They will be used together to determine two operations:
- Whether to use FW locality check
- Whether to use SW fallback on FW locality check failure
The refactor streamlines this by introducing two variables in the hdcp2
link adjustment, while ensuring function pointers are always assigned
and remain independent from policy decisions:
- use_fw_locality_check (bool) -> true if fw locality should be used.
- use_sw_locality_fallback (bool) -> true to reset use_fw_locality_check
back to false and retry on fw locality check failure.

2. Mixed meanings of l_prime_read transition input
l_prime_read originally means if l_prime is read when sw locality check
is used. When FW locality check is used, l_prime_read means if lc init
write, l prime poll and l_prime read combo operation is successful. The
mix of meanings is confusing. The refactor introduces a new variable
l_prime_combo_read to isolate the second meaning into its own variable.

3. Missing specific error code on firmware locality error.
The original change reuses the generic DDC failure error code when
firmware fails to return locality check result. This is not ideal as
DDC failure indicates an error occurred during an I2C/AUX transaction.
FW locality failure could be caused by polling timeout in firmware or
failure to acquire firmware access. Which sits at a higher level of
abstraction above DDC hardware. An incorrect error code could mislead
the debug into a wrong direction.

4. Correcting misplaced comments. The previous implementation of the
firmware locality check resulted in some comments in hdcp2_transition
being incorrectly positioned. This refactor relocates those comments to
their appropriate locations for better clarity.

Reviewed-by: Aric Cyr 
Signed-off-by: Wenjing Liu 
Signed-off-by: Ray Wu 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: add additional hdcp traces

2025-10-20T22:24:53+00:00

[why]
Current hdcp trace only tracks hdcp errors. We need to expand the trace
structure for more tracing information.

[how]
Add following traces for hdcp1:
- attempt_count
- downstream_device_count
Add following traces for hdcp2:
- attempt_count
- downstream_device_count
- hdcp1_device_downstream
- hdcp2_legacy_device_downstream

Reviewed-by: Sung Lee 
Signed-off-by: Wenjing Liu 
Signed-off-by: Aurabindo Pillai 
Signed-off-by: Alex Deucher

drm/amd/display: Add HDCP policy control

2025-09-05T21:38:40+00:00

[Why]
DM should be able to control HDCP retry limit via configurable
parameter.

[How]
Expose a retry_limit parameter for controlling the maximum number of
retries and lift the hardcode out to DM.

Reviewed-by: Nicholas Kazlauskas 
Reviewed-by: Aric Cyr 
Signed-off-by: Oleh Kuzhylnyi 
Signed-off-by: Wayne Lin 
Tested-by: Dan Wheeler 
Signed-off-by: Alex Deucher