Re: [PATCH v2 3/3] drm/bridge: analogix_dp: Add support for optional data-lanes mapping

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Incorrect logical-to-physical lane mapping causes inverted mapping in ANALOGIX_DP_LANE_MAP.
- [High] Potential stack buffer overflow when parsing `data-lanes` if `max_lane_count` exceeds 4.
- [High] Custom lane mapping is not applied to the PHY configuration during link training.
- [Medium] Inconsistent endpoint `reg` matching between lane counting and endpoint fetching.
--

commit 85a24e4079e66f4ed5dd4c98ce61e660ea4f5de4
Author: Damon Ding <damon.ding@rock-chips.com>

drm/bridge: analogix_dp: Add support for optional data-lanes mapping

Parse the optional 'data-lanes' device tree property to support
custom physical lane mapping configuration. If no valid configuration
is found, fall back to the default lane map (0, 1, 2, 3) automatically
and keep the driver running.

> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 8cf6b73bceac0..d53ab25bc57b1 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 = {
>  	.detect = analogix_dp_bridge_detect,
>  };
>  
> +static int analogix_dp_dt_parse_lanes_map(struct analogix_dp_device *dp)
> +{
> +	struct video_info *video_info = &dp->video_info;
> +	struct device_node *endpoint;
> +	u32 tmp[LANE_COUNT4];
> +	u32 map[LANE_COUNT4] = {0, 1, 2, 3};
> +	bool used[LANE_COUNT4] = {false};
> +	int num_lanes;
> +	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);

[Severity: High]
Can this cause a stack buffer overflow if max_lane_count exceeds 4?

On Exynos platforms, max_lane_count is read directly from the
samsung,lane-count device tree property without validation. If a
misconfigured device tree specifies a lane-count greater than 4,
drm_of_get_data_lanes_count_ep() will return a num_lanes value up to
that maximum.

Will the subsequent call to of_property_read_u32_array() then write past
the end of the tmp array?

> +	if (num_lanes < 0)
> +		return -EINVAL;
> +
> +	endpoint = of_graph_get_endpoint_by_regs(dp->dev->of_node, 1, -1);

[Severity: Medium]
Are we matching inconsistent endpoints here?

The earlier call to drm_of_get_data_lanes_count_ep() hardcodes reg = 0 to
search for endpoint@0. However, this lookup via of_graph_get_endpoint_by_regs()
uses reg = -1, which fetches the first endpoint under port 1 regardless of
its address.

If the device tree defines multiple endpoints, could the driver count the lanes
in endpoint@0 but then mistakenly read the data-lanes array from a different
endpoint?

> +	if (!endpoint)
> +		return -EINVAL;
> +
> +	ret = of_property_read_u32_array(endpoint, "data-lanes", tmp, num_lanes);
> +	of_node_put(endpoint);

[ ... ]

> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> index 17347448c6b0b..634fad241e69d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> @@ -137,6 +137,8 @@ struct video_info {
>  
>  	int max_link_rate;
>  	enum link_lane_count_type max_lane_count;
> +
> +	u32 lane_map[LANE_COUNT4];
>  };

[Severity: High]
Is the custom lane mapping applied to the PHY configuration during link
training?

During link training, the driver extracts voltage swing and pre-emphasis values
per logical lane and assigns them directly to the PHY.

Because the DP MAC routes logical lanes to different physical lanes via
the custom mapping, do the analog adjustments need to be applied to the
corresponding mapped physical lanes to avoid breaking link training on
boards utilizing lane mapping?

[ ... ]

> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 38fd8d5014d29..45c7652645a13 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -48,16 +48,15 @@ void analogix_dp_stop_video(struct analogix_dp_device *dp)
>  	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
>  }
>  
> -void analogix_dp_lane_swap(struct analogix_dp_device *dp, bool enable)
> +void analogix_dp_lane_mapping(struct analogix_dp_device *dp)
>  {
> +	u32 *lane_map = dp->video_info.lane_map;
>  	u32 reg;
>  
> -	if (enable)
> -		reg = LANE3_MAP_LOGIC_LANE_0 | LANE2_MAP_LOGIC_LANE_1 |
> -		      LANE1_MAP_LOGIC_LANE_2 | LANE0_MAP_LOGIC_LANE_3;
> -	else
> -		reg = LANE3_MAP_LOGIC_LANE_3 | LANE2_MAP_LOGIC_LANE_2 |
> -		      LANE1_MAP_LOGIC_LANE_1 | LANE0_MAP_LOGIC_LANE_0;
> +	reg = lane_map[0] << LANE0_MAP_SHIFT;
> +	reg |= lane_map[1] << LANE1_MAP_SHIFT;
> +	reg |= lane_map[2] << LANE2_MAP_SHIFT;
> +	reg |= lane_map[3] << LANE3_MAP_SHIFT;

[Severity: High]
Does this write the physical lane index into the logical lane bit-field
instead of the other way around?

The ANALOGIX_DP_LANE_MAP hardware register expects the logic lane number
to be written into the bit-field dedicated to the physical lane. The
current bitwise shift writes the physical lane index into the bit-field
for the logical lane.

For symmetric permutations like <3 2 1 0> this might work by coincidence,
but could this result in an inverted mapping for non-symmetric permutations
(e.g., <1 2 3 0>), causing link training and display output to fail?

>  
>  	writel(reg, dp->reg_base + ANALOGIX_DP_LANE_MAP);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260521114459.1394264-1-damon.ding@rock-chips.com?part=3