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 <[email protected]> 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/[email protected]?part=4
