[PATCH v3 2/2] drm/bridge: analogix_dp: Add support for optional data-lanes mapping
Damon Ding
damon.ding at rock-chips.com
Tue May 26 05:35:30 PDT 2026
Hi Luca,
On 5/26/2026 8:07 PM, Luca Ceresoli wrote:
> On Mon, 25 May 2026 17:47:31 +0800, Damon Ding <damon.ding at rock-chips.com> 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
More information about the Linux-rockchip
mailing list