Re: [PATCH v2 0/6] Fix regulator voting for the Qualcomm SGMII SerDes PHY
Mohd Ayaan Anwar <[email protected]> Tue, 4 Aug 2026 14:06:30 +0530
| Newsgroups | org.kernel.vger.linux-arm-msm,org.infradead.lists.linux-phy,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Aug 04, 2026 at 12:57:56AM +0530, Mohd Ayaan Anwar wrote: > This series corrects this by: > > 1. Fixing the DT binding to describe both named supplies. > 2. Fixing all affected board DTS to use the correct vdda-0p9-supply > and vdda-1p2-supply properties. > 3. Adding bulk regulator support to the PHY driver so it enables both > supplies and sets the proper current loads. > > The patches are sequenced to maintain bisectability. With the driver > change, the PHY framework will continue to vote for the regulator > described by 'phy-supply'. The DT changes which follow then remove > 'phy-supply' in favour of 'vdda-0p9' and 'vdda-1p2'. > Sashiko raises some valid concerns [0]: -- 1. This isn't a bug introduced by this patch, but I noticed that another file in the tree, monaco-monza-som.dtsi, still has the exact same configuration you are fixing here. It retains the deprecated phy-supply property and lacks the required 0.9V rail. Should monaco-monza-som.dtsi be updated similarly in this patch or as a follow-up in this series? 2. This is a pre-existing issue, but does registering the PHY provider before setting the driver data create a race condition here? Looking at the end of qcom_dwmac_sgmii_phy_probe(): provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate); if (IS_ERR(provider)) return PTR_ERR(provider); phy_set_drvdata(phy, data); By calling devm_of_phy_provider_register() first, the PHY is made available to consumers before phy_set_drvdata() initializes the private data. If a consumer (such as a deferred probe workqueue) concurrently looks up the PHY and immediately invokes an operation like phy_power_on(), could qcom_dwmac_sgmii_phy_power_on() read a NULL driver data pointer and cause a NULL pointer dereference when attempting to access data->vregs? -- For 1., I can either post a follow-up patch or add it as part of v3. For 2., this is a genuine pre-existing bug. I will raise a separate patch to move phy_set_drvdata() before devm_of_phy_provider_register() to close the race window. Ayaan [0] https://sashiko.dev/#/patchset/20260804-b4-sgmiieth_serdes_regulator-v2-0-c4bc688177dd@oss.qualcomm.com