Hi Luca,
On 5/26/2026 8:07 PM, Luca Ceresoli wrote:
On Mon, 25 May 2026 17:47:31 +0800, Damon Ding <[email protected]>
wrote:
Hello Damon,
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 8cf6b73bceac..d53ab25bc57b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1234,6 +1234,59 @@ static const struct drm_bridge_funcs
analogix_dp_bridge_funcs = {
[ ... skip 11 lines ... ]
+ int ret, i;
+
+ memcpy(video_info->lane_map, map, sizeof(map));
+
+ num_lanes = drm_of_get_data_lanes_count_ep(dp->dev->of_node, 1, 0, 1,
+ video_info->max_lane_count);
Should num_lanes be > 4, the buffers could overflow. I realize it should
not happen, but analogix_dp_dt_parse_pdata() can set max_lane_count from
the device tree, so a bogus dtb could cause such overflow.
Perhaps you should just (in a separate patch) error out in
analogix_dp_dt_parse_pdata() to prevent this. And maybe even adding an
BUG_ON(lane_count > 4) here.
Otherwise LGTM.
Thank you for the review.
I think it would be a better idea to add a separate patch to validate
the max_link_rate and max_lane_count values for Exynos DP.
I checked the Exynos DP related DTS files:
- The maximum value of samsung,lane-count is 4
- The maximum value of samsung,link-rate is 0x0a, which corresponds to
the HBR lane rate.
Could Marek please help confirm if we can set these as the upper limits
for the checks?
Best regards,
Damon
