Re: [PATCH v3 03/12] phy: phy-mtk-dp: Allow probing with devicetree match

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

On 7/7/26 18:06, sashiko-bot@kernel.org wrote:
> 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 <angelogioacchino.delregno@collabora.com>
> 
> 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?
> 

All of that is exactly why there's a "legacy probe" and a "devicetree probe"
mechanism. It's either one or the other, and the legacy one is there only for
retro compatibility purposes.

If the devicetree sets the PHY node's reg to something unrelated this is not
going to work; it's obvious, and should not even be evaluated as an option.

Magic 8 ball case again?

>> +	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?
> 

That won't happen because as I explained before, the PHY needs to be powered
on with phy_power_on() which calls runtime_pm_get_sync().

In any case, an unpowered PHY will cause a silent loss of configuration with
no SError nor any other crash.

>> +
>>   	phy = devm_phy_create(dev, NULL, &mtk_dp_phy_dev_ops);
> 


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy