Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues: - [High] Hardcoded `PHY_OFFSET` causes out-of-bounds register accesses or resource conflicts when the PHY is probed as a standalone devicetree node. - [High] Hardware registers are accessed in `mtk_dp_phy_configure()` while the PHY device is runtime-suspended, causing a system crash or silent loss of configuration. Pre-existing issues: - [High] Dereferencing `dev->platform_data` before checking if it is NULL leads to a kernel crash. -- --- Patch [3]: [PATCH v3 03/12] phy: phy-mtk-dp: Allow probing with devicetree match --- commit 710ab5488fd0b66b2ea62388b977a4308f99a0c6 Author: AngeloGioacchino Del Regno <[email protected]> phy: phy-mtk-dp: Allow probing with devicetree match Make it possible to decouple the registration of the DisplayPort PHY driver from the DisplayPort IP driver by adding a devicetree match to probe the PHY. In order to retain compatibility with older devicetrees, the legacy code was moved in a mtk_dp_phy_legacy_probe() function. > diff --git a/drivers/phy/mediatek/phy-mtk-dp.c > b/drivers/phy/mediatek/phy-mtk-dp.c > index bf7b3a95e72d2..d241004e28286 100644 > --- a/drivers/phy/mediatek/phy-mtk-dp.c > +++ b/drivers/phy/mediatek/phy-mtk-dp.c [ ... ] > +static int mtk_dp_phy_legacy_probe(struct platform_device *pdev, struct > mtk_dp_phy *dp_phy) > +{ > + struct device *dev = &pdev->dev; > + struct phy *phy; > + int ret; > + > + dp_phy->regmap = *(struct regmap **)dev->platform_data; > + if (!dp_phy->regmap) > + return dev_err_probe(dev, -EINVAL, "No platform data > available\n"); [Severity: High] This is a pre-existing issue, but does casting and dereferencing dev->platform_data before checking if it is NULL lead to a kernel crash? If the driver is bound to a device without platform data via sysfs, this unvalidated pointer will be dereferenced before the check for !dp_phy->regmap can execute. [ ... ] > static int mtk_dp_phy_probe(struct platform_device *pdev) > { > struct device *dev = &pdev->dev; [ ... ] > dp_phy = devm_kzalloc(dev, sizeof(*dp_phy), GFP_KERNEL); > if (!dp_phy) > return -ENOMEM; > > - dp_phy->regmap = regs; > + dp_phy->dev = dev; > + > + /* If there's no devicetree, go for legacy pdev probe */ > + if (!dev->of_node) > + return mtk_dp_phy_legacy_probe(pdev, dp_phy); > + > + base = devm_platform_ioremap_resource(pdev, 0); > + if (IS_ERR(base)) > + return PTR_ERR(base); > + > + dp_phy->regmap = devm_regmap_init_mmio(dev, base, > &mtk_dp_phy_regmap_cfg); [Severity: High] Since the driver hardcodes PHY_OFFSET (0x1000) into its register macros like MTK_DP_PHY_DIG_PLL_CTL_1, will this independent regmap cause out-of-bounds accesses if the devicetree maps the PHY node to its true physical base? If the devicetree instead sets the PHY node's reg to the parent DP IP base to counteract this offset, won't this cause devm_platform_ioremap_resource() to fail with -EBUSY due to resource conflicts between the PHY driver and the DP IP driver? > + if (IS_ERR(dp_phy->regmap)) > + return PTR_ERR(dp_phy->regmap); > + > + ret = devm_pm_runtime_enable(dev); > + if (ret) > + return ret; [Severity: High] By enabling runtime PM here, could mtk_dp_phy_configure() access hardware registers while the PHY device is runtime-suspended? The consumer driver calls phy_configure() without calling phy_power_on(). The PHY framework takes a runtime PM reference during .init and .reset, but explicitly drops it right before returning, and does not take a reference during .configure. When the consumer calls phy_configure(), it writes directly to hardware via regmap_write() and regmap_update_bits() while the device PM usage count is zero. Can this crash the system or cause silent loss of configuration? > + > phy = devm_phy_create(dev, NULL, &mtk_dp_phy_dev_ops); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
