Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Missing NULL check for `dev->platform_data` before dereferencing it in `mtk_dp_phy_probe`. -- --- Patch [2]: [PATCH v2 02/12] phy: phy-mtk-dp: Rename regs to regmap in struct mtk_dp_phy --- commit b41d4072a9780ff4f56cf8b17085088b1f2777ae Author: AngeloGioacchino Del Regno <[email protected]> phy: phy-mtk-dp: Rename regs to regmap in struct mtk_dp_phy This commit renames the regs member of struct mtk_dp_phy to regmap to improve readability and align with common kernel driver naming conventions. > diff --git a/drivers/phy/mediatek/phy-mtk-dp.c > b/drivers/phy/mediatek/phy-mtk-dp.c > index d7024a1443358..bf7b3a95e72d2 100644 > --- a/drivers/phy/mediatek/phy-mtk-dp.c > +++ b/drivers/phy/mediatek/phy-mtk-dp.c [ ... ] > @@ -176,7 +176,7 @@ static int mtk_dp_phy_probe(struct platform_device *pdev) [Severity: High] This is a pre-existing issue, but does mtk_dp_phy_probe() lack a NULL check for dev->platform_data before dereferencing it? If the platform device is probed without platform_data (for example, if manually bound via the sysfs bind interface to a generic platform device lacking this data), dev->platform_data will be NULL. Looking at the code in mtk_dp_phy_probe(): regs = *(struct regmap **)dev->platform_data; if (!regs) return dev_err_probe(dev, -EINVAL, ... Dereferencing dev->platform_data to assign regs before checking if platform_data itself is valid will cause a kernel oops. > if (!dp_phy) > return -ENOMEM; > > - dp_phy->regs = regs; > + dp_phy->regmap = regs; > phy = devm_phy_create(dev, NULL, &mtk_dp_phy_dev_ops); > if (IS_ERR(phy)) > return dev_err_probe(dev, PTR_ERR(phy), -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
