[PATCH 4/5] drm/rockchip: cdn-dp: Support handle lane info without extcon

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incorrect extcon pointer validation logic skips valid extcon devices
--

commit a9e1ff8879a685d4cf4ae0348e11004c03d1dc46
Author: Chaoyi Chen <chaoyi.chen at rock-chips.com>

drm/rockchip: cdn-dp: Support handle lane info without extcon

This commit adds support for getting PHY lane info without the help of extcon
when the Type-C controller is present. It updates multiple functions to verify
the extcon device pointer before using it.

> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index 177e30445ee83..9068118859e21 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c

[ ... ]

> @@ -1121,14 +1130,14 @@ static int cdn_dp_probe(struct platform_device *pdev)
>  		    PTR_ERR(phy) == -EPROBE_DEFER)
>  			return -EPROBE_DEFER;
>  
> -		if (IS_ERR(extcon) || IS_ERR(phy))
> +		if (IS_ERR(phy) || PTR_ERR(extcon) != -ENODEV)
>  			continue;

[Severity: High]
Does this logic skip valid extcon devices?

When extcon_get_edev_by_phandle() returns a valid pointer, PTR_ERR(extcon)
evaluates to the pointer's memory address, which will not equal -ENODEV.

This causes the condition to evaluate to true, executing the continue
statement and bypassing initialization for boards that rely on a valid
extcon device.

>  
>  		port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
>  		if (!port)
>  			return -ENOMEM;
>  
> -		port->extcon = extcon;
> +		port->extcon = IS_ERR(extcon) ? NULL : extcon;
>  		port->phy = phy;
>  		port->dp = dp;
>  		port->id = i;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608070805.88-1-kernel@airkyi.com?part=4