[PATCH net-next v3 1/5] dt-bindings: net: maxlinear: add MxL86211C VDDP supply

[PATCH net-next v3 1/5] dt-bindings: net: maxlinear: add MxL86211C VDDP supply

[Robert Marko]

Describe the optional VDDP supply used by the MxL86211C PHY. Its
voltage determines whether the MDIO, MDC, and MDINT pads use 1.8 V or
3.3 V.

Existing device trees do not describe the supply and rely on the hardware
reset default. Keep the property optional to preserve their compatibility.

Select the MxL86211C PHY ID and nodes using the existing MaxLinear
broken-interrupt property, so this binding is checked during normal DT
validation. Restrict the new supply property to the MxL86211C with the
compatible conditional.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v3:
- Make VDDP optional for existing device trees.
- Select MxL86211C nodes and nodes using the legacy MaxLinear property.
- Replace the empty then branch with a negated compatible condition.

Changes in v2:
- Model VDDP as a supply instead of a regulator provider.
- Select the schema for the MxL86211C PHY ID.

 .../bindings/net/maxlinear,gpy2xx.yaml        | 48 +++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
index 8a3713abd1ca9..53f430e121510 100644
--- a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
+++ b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
@@ -10,10 +10,37 @@ maintainers:
   - Andrew Lunn <andrew@lunn.ch>
   - Michael Walle <michael@walle.cc>
 
+select:
+  anyOf:
+    - properties:
+        compatible:
+          contains:
+            const: ethernet-phy-idc133.5400
+      required:
+        - compatible
+    - required:
+        - maxlinear,use-broken-interrupts
+
 allOf:
   - $ref: ethernet-phy.yaml#
+  - if:
+      not:
+        properties:
+          compatible:
+            contains:
+              const: ethernet-phy-idc133.5400
+        required:
+          - compatible
+    then:
+      properties:
+        vddp-supply: false
 
 properties:
+  vddp-supply:
+    description: |
+      Optional regulator supplying the VDDP pin. Its voltage configures the
+      MDIO, MDC, and MDINT pad voltage and must be either 1.8 V or 3.3 V.
+
   maxlinear,use-broken-interrupts:
     description: |
       Interrupts are broken on some GPY2xx PHYs in that they keep the
@@ -45,4 +72,25 @@ examples:
         };
     };
 
+  - |
+    vddp: regulator-vddp {
+        compatible = "regulator-fixed";
+        regulator-name = "vddp";
+        regulator-min-microvolt = <1800000>;
+        regulator-max-microvolt = <1800000>;
+    };
+
+    ethernet {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        ethernet-phy@0 {
+            compatible = "ethernet-phy-idc133.5400",
+                         "ethernet-phy-ieee802.3-c45";
+            reg = <0>;
+            vddp-supply = <&vddp>;
+
+        };
+    };
+
 ...
-- 
2.56.0

[PATCH net-next v3 2/5] net: phy: mxl-gpy: add MxL86211C VDDP supply

[Robert Marko]

Optionally read the VDDP supply voltage and configure the MxL86211C
MDIO, MDC, and MDINT pads for the matching 1.8 V or 3.3 V level.

Enable an explicitly provided VDDP regulator for the PHY lifetime. Existing
device trees do not describe the supply, so preserve the hardware reset
default when it is absent.

Keep the shared GPY driver buildable without regulator support.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v3:
- Make the VDDP supply optional for existing device trees.
- Enable an explicitly provided regulator for the PHY lifetime.
- Keep the hardware reset default when no supply is described.

Changes in v2:
- Replace the MDIO regulator provider with a VDDP supply consumer.
- Set the pad voltage from the supply's reported voltage.
- Keep the shared driver buildable with CONFIG_REGULATOR=n.

 drivers/net/phy/mxl-gpy.c | 78 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 77 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/mxl-gpy.c b/drivers/net/phy/mxl-gpy.c
index 089a1a9e5bc61..952272faac1e8 100644
--- a/drivers/net/phy/mxl-gpy.c
+++ b/drivers/net/phy/mxl-gpy.c
@@ -14,6 +14,7 @@
 #include <linux/polynomial.h>
 #include <linux/property.h>
 #include <linux/netdevice.h>
+#include <linux/regulator/consumer.h>
 
 /* PHY ID */
 #define PHY_ID_GPYx15B_MASK	0xFFFFFFFC
@@ -110,6 +111,10 @@
 #define VSPEC1_SGMII_ANEN_ANRS	(VSPEC1_SGMII_CTRL_ANEN | \
 				 VSPEC1_SGMII_CTRL_ANRS)
 
+/* Packet Manager Control */
+#define VSPEC1_PM_CTRL		0x0c
+#define VSPEC1_PM_CTRL_MDIO_VOL	BIT(14)
+
 /* Temperature sensor */
 #define VSPEC1_TEMP_STA	0x0E
 #define VSPEC1_TEMP_STA_DATA	GENMASK(9, 0)
@@ -140,6 +145,7 @@ struct gpy_priv {
 	u8 fw_minor;
 	u32 wolopts;
 	u64 rx_errors;
+	struct regulator *vddp;
 
 	/* It takes 3 seconds to fully switch out of loopback mode before
 	 * it can safely re-enter loopback mode. Record the time when
@@ -390,6 +396,76 @@ static int gpy_probe(struct phy_device *phydev)
 	return 0;
 }
 
+static int mxl86211c_configure_mdio_voltage(struct phy_device *phydev,
+					    struct regulator *vddp)
+{
+	int voltage;
+	int val;
+
+	voltage = regulator_get_voltage(vddp);
+	if (voltage < 0)
+		return voltage;
+
+	switch (voltage) {
+	case 1800000:
+		val = VSPEC1_PM_CTRL_MDIO_VOL;
+		break;
+	case 3300000:
+		val = 0;
+		break;
+	default:
+		phydev_err(phydev, "unsupported VDDP voltage: %d\n", voltage);
+		return -EINVAL;
+	}
+
+	return phy_modify_mmd(phydev, MDIO_MMD_VEND1, VSPEC1_PM_CTRL,
+			      VSPEC1_PM_CTRL_MDIO_VOL, val);
+}
+
+static void mxl86211c_disable_vddp(void *data)
+{
+	regulator_disable(data);
+}
+
+static int mxl86211c_probe(struct phy_device *phydev)
+{
+	struct device *dev = &phydev->mdio.dev;
+	struct gpy_priv *priv;
+	struct regulator *vddp;
+	int ret;
+
+	vddp = devm_regulator_get_optional(dev, "vddp");
+	if (PTR_ERR_OR_ZERO(vddp) == -ENODEV)
+		vddp = NULL;
+	else if (IS_ERR(vddp))
+		return dev_err_probe(dev, PTR_ERR(vddp),
+				     "failed to get VDDP supply\n");
+
+	if (vddp) {
+		ret = regulator_enable(vddp);
+		if (ret)
+			return dev_err_probe(dev, ret,
+					     "failed to enable VDDP supply\n");
+
+		ret = devm_add_action_or_reset(dev, mxl86211c_disable_vddp, vddp);
+		if (ret)
+			return ret;
+
+		ret = mxl86211c_configure_mdio_voltage(phydev, vddp);
+		if (ret)
+			return ret;
+	}
+
+	ret = gpy_probe(phydev);
+	if (ret)
+		return ret;
+
+	priv = phydev->priv;
+	priv->vddp = vddp;
+
+	return 0;
+}
+
 static bool gpy_sgmii_need_reaneg(struct phy_device *phydev)
 {
 	struct gpy_priv *priv = phydev->priv;
@@ -1406,7 +1482,7 @@ static struct phy_driver gpy_drivers[] = {
 		.name		= "Maxlinear Ethernet MxL86211C",
 		.get_features	= genphy_c45_pma_read_abilities,
 		.config_init	= gpy21x_config_init,
-		.probe		= gpy_probe,
+		.probe		= mxl86211c_probe,
 		.inband_caps	= gpy_inband_caps,
 		.config_inband	= gpy_config_inband,
 		.suspend	= genphy_suspend,
-- 
2.56.0

Re: [PATCH net-next v3 2/5] net: phy: mxl-gpy: add MxL86211C VDDP supply

[Andrew Lunn]

> +/* Packet Manager Control */
> +#define VSPEC1_PM_CTRL		0x0c
> +#define VSPEC1_PM_CTRL_MDIO_VOL	BIT(14)

Is this Packet or Power?

	Andrew

Re: [PATCH net-next v3 2/5] net: phy: mxl-gpy: add MxL86211C VDDP supply

[Robert Marko]

On Tue, Oct 20, 2026 at 2:39 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > +/* Packet Manager Control */
> > +#define VSPEC1_PM_CTRL               0x0c
> > +#define VSPEC1_PM_CTRL_MDIO_VOL      BIT(14)
>
> Is this Packet or Power?

The datasheet calls it Packet Manager Control.

Regards,
Robert
>
>         Andrew



-- 
Robert Marko
Staff Embedded Linux Engineer
Sartura d.d.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko@sartura.hr
Web: www.sartura.hr

Re: [PATCH net-next v3 2/5] net: phy: mxl-gpy: add MxL86211C VDDP supply

[Andrew Lunn]

On Tue, Oct 20, 2026 at 02:49:01PM +0200, Robert Marko wrote:
> On Tue, Oct 20, 2026 at 2:39 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > > +/* Packet Manager Control */
> > > +#define VSPEC1_PM_CTRL               0x0c
> > > +#define VSPEC1_PM_CTRL_MDIO_VOL      BIT(14)
> >
> > Is this Packet or Power?
> 
> The datasheet calls it Packet Manager Control.

O.K, great. Putting Packet would be the sort of dumb typo my
brain/finger connection would do, so i just wanted to check.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

Re: [PATCH net-next v3 2/5] net: phy: mxl-gpy: add MxL86211C VDDP supply

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 2 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] In this commit, the MxL86211C pad-voltage select
  (VSPEC1_PM_CTRL_MDIO_VOL, bit 14 of VSPEC1_PM_CTRL) is written only…
- [Medium] The VDDP regulator powers the MDIO/MDC/MDINT pads, but
  mxl86211c_probe() (drivers/net/phy/mxl-gpy.c:437-457) first gets and…

--

net: phy: mxl-gpy: add MxL86211C VDDP supply

This adds an optional VDDP supply consumer to the MxL86211C probe. If the
supply is described, it is enabled for the PHY lifetime, and the
VSPEC1_PM_CTRL MDIO pad voltage bit is set to match the reported 1.8 V or
3.3 V level. If the supply is absent, the hardware reset default is kept.

> diff --git a/drivers/net/phy/mxl-gpy.c b/drivers/net/phy/mxl-gpy.c
> index 089a1a9e5bc6..952272faac1e 100644
> --- a/drivers/net/phy/mxl-gpy.c
> +++ b/drivers/net/phy/mxl-gpy.c

[ ... ]

> +static int mxl86211c_probe(struct phy_device *phydev)
> +{
> +	struct device *dev = &phydev->mdio.dev;
> +	struct gpy_priv *priv;
> +	struct regulator *vddp;
> +	int ret;
> +
> +	vddp = devm_regulator_get_optional(dev, "vddp");
> +	if (PTR_ERR_OR_ZERO(vddp) == -ENODEV)
> +		vddp = NULL;
> +	else if (IS_ERR(vddp))
> +		return dev_err_probe(dev, PTR_ERR(vddp),
> +				     "failed to get VDDP supply\n");
> +
> +	if (vddp) {
> +		ret = regulator_enable(vddp);

[Severity: Medium]
Can a switchable vddp-supply that is off at boot work with this ordering?
VDDP powers the MDIO/MDC/MDINT pads. Here it is first enabled from the PHY
driver's .probe callback. By then phylib has already accessed the PHY over
MDIO and has already released its reset.

During discovery, fwnode_mdiobus_register_phy() reads the PHY ID over MDIO
before any driver binds:

drivers/net/mdio/fwnode_mdio.c:fwnode_mdiobus_register_phy() {
    ...
	is_c45 = fwnode_device_is_compatible(child, "ethernet-phy-ieee802.3-c45");
	if (is_c45 || fwnode_get_phy_id(child, &phy_id))
		phy = get_phy_device(bus, addr, is_c45);
    ...
}

The binding's vddp-supply example uses compatible =
"ethernet-phy-idc133.5400", "ethernet-phy-ieee802.3-c45". That makes is_c45
true, so the ID reads go out over unpowered pads.

Wouldn't registration fail at that point, before mxl86211c_probe() gets to
enable VDDP?

If only the ID compatible is listed, discovery is skipped. Even then,
phy_probe() deasserts reset before it calls the driver probe:

drivers/net/phy/phy_device.c:phy_probe() {
    ...
	/* Deassert the reset signal */
	phy_device_reset(phydev, 0);

	if (phydev->drv->probe) {
		err = phydev->drv->probe(phydev);
    ...
}

So the PHY comes out of reset while VDDP is still off. mxl86211c_probe()
then enables VDDP and writes VSPEC1_PM_CTRL straight away, with no reset
cycle after power-up.

This seems to work only when VDDP is already on (always-on, boot-on, or
left on by the bootloader). Should the commit message or the binding
document that limitation? Or should the supply be handled earlier?

> +		if (ret)
> +			return dev_err_probe(dev, ret,
> +					     "failed to enable VDDP supply\n");
> +
> +		ret = devm_add_action_or_reset(dev, mxl86211c_disable_vddp, vddp);
> +		if (ret)
> +			return ret;
> +
> +		ret = mxl86211c_configure_mdio_voltage(phydev, vddp);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	ret = gpy_probe(phydev);
> +	if (ret)
> +		return ret;
> +
> +	priv = phydev->priv;
> +	priv->vddp = vddp;
> +
> +	return 0;
> +}

[ ... ]

> @@ -1406,7 +1482,7 @@ static struct phy_driver gpy_drivers[] = {
>  		.name		= "Maxlinear Ethernet MxL86211C",
>  		.get_features	= genphy_c45_pma_read_abilities,
>  		.config_init	= gpy21x_config_init,
> -		.probe		= gpy_probe,
> +		.probe		= mxl86211c_probe,

[Severity: Medium]
Is the VSPEC1_PM_CTRL_MDIO_VOL setting lost after a later hardware reset?
This patch writes the bit only once, from mxl86211c_probe(). The MxL86211C
entry still uses gpy21x_config_init(), which never writes VSPEC1_PM_CTRL.

On a board with reset-gpios, a detach/attach cycle runs:

phy_detach()
  phy_device_reset(phydev, 1)
phy_attach_direct()
  phy_init_hw()
    phy_device_reset(phydev, 0)
    phydev->drv->config_init() -> gpy21x_config_init()

After that the pad mode is back at its reset default and no longer matches
a 1.8 V VDDP. A suspend that drops PHY power would have the same result.
This commit stores priv->vddp but never reads it.

A later commit in this series, "net: phy: mxl-gpy: release MxL86211C Super
Isolate", seems to fix this. It switches the entry to
mxl86211c_config_init(), which calls
mxl86211c_configure_mdio_voltage(phydev, priv->vddp) whenever priv->vddp is
set. Before this patch the bit was never written at all.

Could the setting be restored from config_init in this patch, so that the
intermediate commit is correct on its own?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261020093655.344585-1-robert.marko%40sartura.hr

[PATCH net-next v3 3/5] net: phy: mxl-gpy: release MxL86211C Super Isolate

[Robert Marko]

The MxL86211C can be strapped into Super Isolate mode, leaving the PHY
halted after reset until software releases it.

Release Super Isolate before gpy_probe() reads the firmware version. Do it
again in config_init, where optional VDDP setup is reapplied after each
hardware reset.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v3:
- Release Super Isolate during probe before reading the firmware version.
- Reapply the MDIO pad voltage only when a VDDP supply is provided.

Changes in v2:
- Move Super Isolate release from probe to config_init for resets.
- Reapply the MDIO pad voltage before releasing Super Isolate.

 drivers/net/phy/mxl-gpy.c | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/mxl-gpy.c b/drivers/net/phy/mxl-gpy.c
index 952272faac1e8..dba0777158b2d 100644
--- a/drivers/net/phy/mxl-gpy.c
+++ b/drivers/net/phy/mxl-gpy.c
@@ -114,6 +114,7 @@
 /* Packet Manager Control */
 #define VSPEC1_PM_CTRL		0x0c
 #define VSPEC1_PM_CTRL_MDIO_VOL	BIT(14)
+#define VSPEC1_PM_CTRL_SI	BIT(12)		/* Super Isolate */
 
 /* Temperature sensor */
 #define VSPEC1_TEMP_STA	0x0E
@@ -427,6 +428,30 @@ static void mxl86211c_disable_vddp(void *data)
 	regulator_disable(data);
 }
 
+static int mxl86211c_release_super_isolate(struct phy_device *phydev)
+{
+	return phy_modify_mmd(phydev, MDIO_MMD_VEND1, VSPEC1_PM_CTRL,
+			      VSPEC1_PM_CTRL_SI, 0);
+}
+
+static int mxl86211c_config_init(struct phy_device *phydev)
+{
+	struct gpy_priv *priv = phydev->priv;
+	int ret;
+
+	if (priv->vddp) {
+		ret = mxl86211c_configure_mdio_voltage(phydev, priv->vddp);
+		if (ret)
+			return ret;
+	}
+
+	ret = mxl86211c_release_super_isolate(phydev);
+	if (ret)
+		return ret;
+
+	return gpy21x_config_init(phydev);
+}
+
 static int mxl86211c_probe(struct phy_device *phydev)
 {
 	struct device *dev = &phydev->mdio.dev;
@@ -456,6 +481,10 @@ static int mxl86211c_probe(struct phy_device *phydev)
 			return ret;
 	}
 
+	ret = mxl86211c_release_super_isolate(phydev);
+	if (ret)
+		return ret;
+
 	ret = gpy_probe(phydev);
 	if (ret)
 		return ret;
@@ -1481,7 +1510,7 @@ static struct phy_driver gpy_drivers[] = {
 		PHY_ID_MATCH_MODEL(PHY_ID_MXL86211C),
 		.name		= "Maxlinear Ethernet MxL86211C",
 		.get_features	= genphy_c45_pma_read_abilities,
-		.config_init	= gpy21x_config_init,
+		.config_init	= mxl86211c_config_init,
 		.probe		= mxl86211c_probe,
 		.inband_caps	= gpy_inband_caps,
 		.config_inband	= gpy_config_inband,
-- 
2.56.0

Re: [PATCH net-next v3 3/5] net: phy: mxl-gpy: release MxL86211C Super Isolate

[Andrew Lunn]

On Tue, Oct 20, 2026 at 11:35:36AM +0200, Robert Marko wrote:
> The MxL86211C can be strapped into Super Isolate mode, leaving the PHY
> halted after reset until software releases it.
> 
> Release Super Isolate before gpy_probe() reads the firmware version. Do it
> again in config_init, where optional VDDP setup is reapplied after each
> hardware reset.

This needs expanding a bit. All reset actions by the core should
happen before probe. So why is releasing isolate in probe not
sufficient?

If the MDIO bus voltages are lost, what else is lost? Should
phy_init_hw() be called again?

	Andrew

Re: [PATCH net-next v3 3/5] net: phy: mxl-gpy: release MxL86211C Super Isolate

[Robert Marko]

On Tue, Oct 20, 2026 at 2:48 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Tue, Oct 20, 2026 at 11:35:36AM +0200, Robert Marko wrote:
> > The MxL86211C can be strapped into Super Isolate mode, leaving the PHY
> > halted after reset until software releases it.
> >
> > Release Super Isolate before gpy_probe() reads the firmware version. Do it
> > again in config_init, where optional VDDP setup is reapplied after each
> > hardware reset.
>
> This needs expanding a bit. All reset actions by the core should
> happen before probe. So why is releasing isolate in probe not
> sufficient?
>
> If the MDIO bus voltages are lost, what else is lost? Should
> phy_init_hw() be called again?

I think that Sashiko confused me, it claimed that PHY HW reset could
happen during interface up/down, etc, so these would be lost.

Is that correct?

Cause if PHY HW reset only happens before probe, then doing the
voltage and SI in .probe is fine.

Regards,
Robert

>
>         Andrew



-- 
Robert Marko
Staff Embedded Linux Engineer
Sartura d.d.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko@sartura.hr
Web: www.sartura.hr

Re: [PATCH net-next v3 3/5] net: phy: mxl-gpy: release MxL86211C Super Isolate

[Andrew Lunn]

> I think that Sashiko confused me, it claimed that PHY HW reset could
> happen during interface up/down, etc, so these would be lost.
> 
> Is that correct?

It is easy to put a printk() in the reset code. Just make sure you get
both. There is MDIO bus reset as a whole, and individual PHY reset.

Also check out suspend/resume, with and without WoL, if that is a use
case you are interested in. It could be suspend without WoL might
cause a reset? And if the board actually powers the PHY off/on, i
assume the strapping defaults are reapplied.

      Andrew

Re: [PATCH net-next v3 3/5] net: phy: mxl-gpy: release MxL86211C Super Isolate

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The concern is that the patch lacks a Fixes: tag.

--

net: phy: mxl-gpy: release MxL86211C Super Isolate

This patch releases Super Isolate mode on the MxL86211C PHY in
mxl86211c_probe(), before gpy_probe() reads the firmware version. It
also adds a new mxl86211c_config_init(), which reapplies the optional
VDDP MDIO voltage and releases Super Isolate again after each hardware
reset.

> diff --git a/drivers/net/phy/mxl-gpy.c b/drivers/net/phy/mxl-gpy.c
> index 952272faac1e..dba0777158b2 100644
> --- a/drivers/net/phy/mxl-gpy.c
> +++ b/drivers/net/phy/mxl-gpy.c

[ ... ]

> +static int mxl86211c_config_init(struct phy_device *phydev)
> +{
> +	struct gpy_priv *priv = phydev->priv;
> +	int ret;
> +
> +	if (priv->vddp) {
> +		ret = mxl86211c_configure_mdio_voltage(phydev, priv->vddp);
> +		if (ret)
> +			return ret;
> +	}

[ ... ]

> @@ -456,6 +481,10 @@ static int mxl86211c_probe(struct phy_device *phydev)
>  			return ret;
>  	}
>  
> +	ret = mxl86211c_release_super_isolate(phydev);
> +	if (ret)
> +		return ret;
> +
>  	ret = gpy_probe(phydev);
>  	if (ret)
>  		return ret;

[Severity: Low]
This isn't a bug, but should this patch have a Fixes: tag?

Commit 9d844da693d6d ("net: phy: mxl-gpy: add support for MxL86211C")
added MxL86211C support without any Super Isolate handling. Boards
strapped into Super Isolate would never have come up with that driver.

That said, this looks more like support for a strap configuration the
driver never handled than a fix for a regression.

There is also a dependency. mxl86211c_config_init() uses priv->vddp
and mxl86211c_configure_mdio_voltage(), which come from the previous
patch in the series ("net: phy: mxl-gpy: add MxL86211C VDDP supply").
A Fixes: tag pointing at 9d844da693d6d would trigger a stable backport
that does not apply on its own.

Leaving the tag off seems reasonable for a net-next feature series.
I am raising it only in case the maintainers see it differently.

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261020093655.344585-1-robert.marko%40sartura.hr

[PATCH net-next v3 4/5] dt-bindings: net: maxlinear: add MxL86211C lane mapping support

[Robert Marko]

Describe the optional board-level mapping from physical TPI lanes to the
MxL86211C analog front ends (ASPs). This allows DTS to describe wiring
that differs from the hardware reset mapping.

Select nodes using the new property so invalid uses are checked even
without the MxL86211C compatible.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v3:
- Select nodes using the lane-map property so misuse is validated.
- Restrict the property through the negated compatible condition.

Changes in v2:
- Define the lane-map property at the top level for type checking.
- Describe ASPs as analog front ends.

 .../bindings/net/maxlinear,gpy2xx.yaml        | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
index 53f430e121510..7b6140baf1757 100644
--- a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
+++ b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
@@ -20,6 +20,8 @@ select:
         - compatible
     - required:
         - maxlinear,use-broken-interrupts
+    - required:
+        - maxlinear,lane-asp-map
 
 allOf:
   - $ref: ethernet-phy.yaml#
@@ -34,6 +36,7 @@ allOf:
     then:
       properties:
         vddp-supply: false
+        maxlinear,lane-asp-map: false
 
 properties:
   vddp-supply:
@@ -41,6 +44,21 @@ properties:
       Optional regulator supplying the VDDP pin. Its voltage configures the
       MDIO, MDC, and MDINT pad voltage and must be either 1.8 V or 3.3 V.
 
+  maxlinear,lane-asp-map:
+    description: |
+      Mapping of physical TPI lanes A through D to analog front ends (ASPs)
+      A through D. The array index identifies the physical TPI lane, while
+      its value identifies the analog front end, encoded as 0 through 3.
+      Each analog front end must be mapped exactly once. Omit the property to
+      retain the hardware reset mapping.
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 4
+    maxItems: 4
+    uniqueItems: true
+    items:
+      minimum: 0
+      maximum: 3
+
   maxlinear,use-broken-interrupts:
     description: |
       Interrupts are broken on some GPY2xx PHYs in that they keep the
@@ -90,6 +108,9 @@ examples:
             reg = <0>;
             vddp-supply = <&vddp>;
 
+            /* Swap physical TPI lanes C and D. */
+            maxlinear,lane-asp-map = <0 1 3 2>;
+
         };
     };
 
-- 
2.56.0

Re: [PATCH net-next v3 4/5] dt-bindings: net: maxlinear: add MxL86211C lane mapping support

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] Concern: the binding adds `maxlinear,lane-asp-map` for the
  MxL86211C, but no driver code reads it, so the title "add MxL86211C…

--

dt-bindings: net: maxlinear: add MxL86211C lane mapping support

This patch documents an optional maxlinear,lane-asp-map property for the
MxL86211C. The property describes how the physical TPI lanes are wired to
the analog front ends (ASPs). The select block now also matches nodes that
carry the property, and the property is rejected for non-MxL86211C
compatibles.

> diff --git a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
> index 53f430e12151..7b6140baf175 100644
> --- a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
> +++ b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml

[ ... ]

> @@ -41,6 +44,21 @@ properties:
>        Optional regulator supplying the VDDP pin. Its voltage configures the
>        MDIO, MDC, and MDINT pad voltage and must be either 1.8 V or 3.3 V.
>  
> +  maxlinear,lane-asp-map:
> +    description: |
> +      Mapping of physical TPI lanes A through D to analog front ends (ASPs)
> +      A through D. The array index identifies the physical TPI lane, while
> +      its value identifies the analog front end, encoded as 0 through 3.
> +      Each analog front end must be mapped exactly once. Omit the property to
> +      retain the hardware reset mapping.
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 4
> +    maxItems: 4
> +    uniqueItems: true
> +    items:
> +      minimum: 0
> +      maximum: 3
> +

[Severity: Low]
The subject says "add MxL86211C lane mapping support", but this commit
only documents maxlinear,lane-asp-map. Nothing in this commit reads the
property. Does the driver support come in a separate patch?

The next patch in the series appears to cover it. "net: phy: mxl-gpy:
support MxL86211C lane mapping" adds mxl86211c_configure_lane_asp_map() to
drivers/net/phy/mxl-gpy.c. That function:

  - reads the property with device_property_count_u32() and
    device_property_read_u32_array()
  - checks that each value is in the range 0 to 3 and appears only once
  - writes VSPEC1_LANE_ASP_MAP with phy_modify_mmd()

mxl86211c_config_init() calls it, so the mapping is programmed again after
each hardware reset.

At the end of the series the property has an in-tree user, so this looks
resolved. It is noted here only for completeness.

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261020093655.344585-1-robert.marko%40sartura.hr

[PATCH net-next v3 5/5] net: phy: mxl-gpy: support MxL86211C lane mapping

[Robert Marko]

Configure the MxL86211C mapping from physical TPI lanes to analog
front ends (ASPs) when specified in DTS.

Leave the hardware reset mapping untouched when the optional property
is absent.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
Changes in v3:
- Reject an incorrectly sized lane map before reading its values.

Changes in v2:
- Preserve unrelated register bits when updating the lane map.

 drivers/net/phy/mxl-gpy.c | 53 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/drivers/net/phy/mxl-gpy.c b/drivers/net/phy/mxl-gpy.c
index dba0777158b2d..b71ed2bef3e5d 100644
--- a/drivers/net/phy/mxl-gpy.c
+++ b/drivers/net/phy/mxl-gpy.c
@@ -116,6 +116,13 @@
 #define VSPEC1_PM_CTRL_MDIO_VOL	BIT(14)
 #define VSPEC1_PM_CTRL_SI	BIT(12)		/* Super Isolate */
 
+/* TPI lane to ASP map */
+#define VSPEC1_LANE_ASP_MAP	0x14
+#define VSPEC1_LANE_ASP_MAP_A	GENMASK(1, 0)
+#define VSPEC1_LANE_ASP_MAP_B	GENMASK(3, 2)
+#define VSPEC1_LANE_ASP_MAP_C	GENMASK(5, 4)
+#define VSPEC1_LANE_ASP_MAP_D	GENMASK(7, 6)
+
 /* Temperature sensor */
 #define VSPEC1_TEMP_STA	0x0E
 #define VSPEC1_TEMP_STA_DATA	GENMASK(9, 0)
@@ -434,6 +441,48 @@ static int mxl86211c_release_super_isolate(struct phy_device *phydev)
 			      VSPEC1_PM_CTRL_SI, 0);
 }
 
+static int mxl86211c_configure_lane_asp_map(struct phy_device *phydev)
+{
+	struct device *dev = &phydev->mdio.dev;
+	u32 lane_asp_map[4];
+	u16 val;
+	unsigned int seen = 0;
+	int i, ret;
+
+	if (!device_property_present(dev, "maxlinear,lane-asp-map"))
+		return 0;
+
+	ret = device_property_count_u32(dev, "maxlinear,lane-asp-map");
+	if (ret < 0)
+		return ret;
+	if (ret != ARRAY_SIZE(lane_asp_map))
+		return -EINVAL;
+
+	ret = device_property_read_u32_array(dev, "maxlinear,lane-asp-map",
+					     lane_asp_map,
+					     ARRAY_SIZE(lane_asp_map));
+	if (ret)
+		return ret;
+
+	for (i = 0; i < ARRAY_SIZE(lane_asp_map); i++) {
+		if (lane_asp_map[i] > 3 || seen & BIT(lane_asp_map[i]))
+			return -EINVAL;
+
+		seen |= BIT(lane_asp_map[i]);
+	}
+
+	val = FIELD_PREP(VSPEC1_LANE_ASP_MAP_A, lane_asp_map[0]) |
+	      FIELD_PREP(VSPEC1_LANE_ASP_MAP_B, lane_asp_map[1]) |
+	      FIELD_PREP(VSPEC1_LANE_ASP_MAP_C, lane_asp_map[2]) |
+	      FIELD_PREP(VSPEC1_LANE_ASP_MAP_D, lane_asp_map[3]);
+
+	return phy_modify_mmd(phydev, MDIO_MMD_VEND1, VSPEC1_LANE_ASP_MAP,
+			      VSPEC1_LANE_ASP_MAP_A |
+			      VSPEC1_LANE_ASP_MAP_B |
+			      VSPEC1_LANE_ASP_MAP_C |
+			      VSPEC1_LANE_ASP_MAP_D, val);
+}
+
 static int mxl86211c_config_init(struct phy_device *phydev)
 {
 	struct gpy_priv *priv = phydev->priv;
@@ -445,6 +494,10 @@ static int mxl86211c_config_init(struct phy_device *phydev)
 			return ret;
 	}
 
+	ret = mxl86211c_configure_lane_asp_map(phydev);
+	if (ret)
+		return ret;
+
 	ret = mxl86211c_release_super_isolate(phydev);
 	if (ret)
 		return ret;
-- 
2.56.0

Re: [PATCH net-next v3 1/5] dt-bindings: net: maxlinear: add MxL86211C VDDP supply

[Jakub Kicinski]

On Tue, 20 Oct 2026 11:35:34 +0200 Robert Marko wrote:
> Describe the optional VDDP supply used by the MxL86211C PHY. Its
> voltage determines whether the MDIO, MDC, and MDINT pads use 1.8 V or
> 3.3 V.

Please note that net-next is now closed.

Re: [PATCH net-next v3 1/5] dt-bindings: net: maxlinear: add MxL86211C VDDP supply

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] At this commit, the binding adds `vddp-supply`
  (Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml,…
- [Low] Before this patch, maxlinear,gpy2xx.yaml had no `select`, no
  `properties/compatible` and no `$nodename`.

--

dt-bindings: net: maxlinear: add MxL86211C VDDP supply

This commit adds an optional vddp-supply property to the MaxLinear GPY2xx
PHY binding and limits it to the MxL86211C (ethernet-phy-idc133.5400). It
also adds a select statement, so the schema now applies to nodes with that
PHY ID or with the maxlinear,use-broken-interrupts property. A second
example showing the supply is added too.

> diff --git a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
> index 8a3713abd1ca..53f430e12151 100644
> --- a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
> +++ b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
> @@ -10,10 +10,37 @@ maintainers:
>    - Andrew Lunn <andrew@lunn.ch>
>    - Michael Walle <michael@walle.cc>
>  
> +select:
> +  anyOf:
> +    - properties:
> +        compatible:
> +          contains:
> +            const: ethernet-phy-idc133.5400
> +      required:
> +        - compatible
> +    - required:
> +        - maxlinear,use-broken-interrupts

[Severity: Low]
Will this select branch make the first example in this file fail
dt_binding_check?

Before this patch the schema had no select, no compatible and no
$nodename. dtschema therefore generated a select that matched nothing, and
the existing dependency was never checked:

dependencies:
  maxlinear,use-broken-interrupts: [ interrupts ]

With this branch, every node that has maxlinear,use-broken-interrupts is
now selected. The first example has that property, but it uses
interrupts-extended instead of interrupts:

        ethernet-phy@0 {
            reg = <0>;
            interrupts-extended = <&intc 0>;
            maxlinear,use-broken-interrupts;
        };

If the dtschema interrupts fixup only rewrites properties and required, and
not dependencies, wouldn't this report interrupts as a missing dependency
of maxlinear,use-broken-interrupts? Real DTs that wire the GPY2xx IRQ with
interrupts-extended would get the same dtbs_check error.

The example and the dependency are unchanged at the end of the series.
Could the dependency accept either interrupts or interrupts-extended (for
example a oneOf of required: [interrupts] and
required: [interrupts-extended])? Or could the example use interrupts?

> +
>  allOf:

[ ... ]

>  properties:
> +  vddp-supply:
> +    description: |
> +      Optional regulator supplying the VDDP pin. Its voltage configures the
> +      MDIO, MDC, and MDINT pad voltage and must be either 1.8 V or 3.3 V.
> +

[Severity: Low]
Does anything use vddp-supply at this commit? The MxL86211C entry in
gpy_drivers[] in drivers/net/phy/mxl-gpy.c still uses gpy_probe() and
gpy21x_config_init(). Neither of them gets or enables a regulator.

Suppose a DT points vddp-supply at a switchable regulator that lacks
regulator-always-on. Could the rail stay off, or be turned off by the
unused-regulator cleanup, leaving the MDIO, MDC and MDINT pads without
power?

The next patch in the series, "net: phy: mxl-gpy: add MxL86211C VDDP
supply", fixes this. It adds mxl86211c_probe(), which calls
devm_regulator_get_optional(dev, "vddp") and regulator_enable(). It also
adds mxl86211c_config_init(), which reapplies the pad voltage after reset.
So only a kernel built at exactly this commit is affected.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261020093655.344585-1-robert.marko%40sartura.hr