Re: [PATCH v6 3/5] drm/bridge: analogix_dp: Restore mandatory samsung DP DT properties

["Luca Ceresoli" <luca.ceresoli@bootlin.com>]

Hello Damon,

On Wed Jul 15, 2026 at 10:32 AM CEST, Damon Ding wrote:
> On 7/7/2026 12:17 PM, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>> - [Critical] Failing probe when deprecated DT properties are missing breaks DT ABI and prevents their deprecation.
>> --
>>
>> --- Patch [3]: [PATCH v6 3/5] drm/bridge: analogix_dp: Restore mandatory samsung DP DT properties ---
>> commit b573dba50acc6087122ffa4a65680322f4d004f8
>> Author: Damon Ding <damon.ding@rock-chips.com>
>>
>> drm/bridge: analogix_dp: Restore mandatory samsung DP DT properties
>>
>> This commit reverts a change that made the samsung,link-rate and
>> samsung,lane-count properties optional for Exynos DP. It adds error checking
>> to fail the probe early if these properties are missing, aiming to prevent
>> link training failures caused by zero values.
>>
>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> index 8cf6b73bceac0..293d8adfe9856 100644
>>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> [ ... ]
>>> @@ -1258,10 +1259,14 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
>>>   		 * NOTE: those property parseing code is used for
>>>   		 * providing backward compatibility for samsung platform.
>>>   		 */
>>> -		of_property_read_u32(dp_node, "samsung,link-rate",
>>> -				     &video_info->max_link_rate);
>>> -		of_property_read_u32(dp_node, "samsung,lane-count",
>>> -				     &video_info->max_lane_count);
>>> +		if (of_property_read_u32(dp_node, "samsung,link-rate", &val))
>>> +			return dev_err_probe(dp->dev, -EINVAL,
>>> +					     "Failed to get samsung,link-rate\n");
>>
>> [Severity: Critical]
>> Does failing the probe when this property is missing break the DT ABI?
>>
>> Since samsung,link-rate is a deprecated property, a modern schema-compliant
>> Device Tree might intentionally omit it. If a system boots with such a DT,
>> this check will fail the probe with -EINVAL and disable the display.
>>
>> Could the driver instead fall back to hardware maximums or sensible defaults
>> when the deprecated property is absent, rather than returning an error?
>>
>
> I'm afraid it's difficult to provide a universal sensible default value
> here.
>
> The samsung,lane-count and samsung,link-rate values vary significantly
> across Exynos DP device trees, so a generic fallback to hardware
> maximums cannot guarantee stable link training.
>
> Even though these two properties are marked deprecated, all existing DTS
> files in our projects have already populated them completely. Moreover,
> the current link training logic relies on these two parameters; omitting
> either will directly cause link training failures at runtime.
>
> Therefore, retaining the mandatory property check in probe is a
> reasonable approach for now.

I'm still not convinced we should turn an optional property into mandatory,
after having been optional since 2016 (based on the commit in the Fixes:
tag).

The sure thing is we cannot break existing devices which upgrade to a new
kernel.

Se the question is: if a device is missing one of these properties, or
both, what happens? The video_info->max_link_rate and/or
video_info->max_lane_count will be zero, correct? And if they are zero, is
there even a remote possibility that the device will work somehow, maybe
only with some rare low resolution or whatever?

If the answer is "yes, there is a remote possibility that one sich device,
with some maybe rare configuration, will work", then no, we cannot make
this property mandatory now. There can be devices out there working without
these proberties, and they would be broken.

If the answer is "there is no way at all a device can work without one or
both properties", with a good explanation based on the code flow and
hardware docs, then we can consider this change.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com