Re: [PATCH net v1] mlxbf-gige: Support workaround for MDIO GPIO degradation bug

[Andrew Lunn <andrew@lunn.ch>]

On Thu, Jul 03, 2025 at 06:51:52PM +0000, Asmaa Mnebhi wrote:
>  > > > You need to put the MDIO bus device into its own pm_domain. Try
> > > > calling dev_pm_domain_set() to separate the MDIO bus from the MAC
> > > > driver in terms of power domains. ethtool will then power on/off the
> > > > MAC but leave the MDIO bus alone.
> > > >
> > 
> > > Using dev_pm_domain_set() has the same effect as
> > SET_RUNTIME_PM_OPS. The dev struct is shared so ethtool is still calling the
> > suspend/resume.
> > >
> > > int mlxbf_gige_mdio_probe(struct platform_device *pdev, struct
> > > mlxbf_gige *priv)  {
> > >         struct device *dev = &pdev->dev; @@ -390,14 +418,27 @@ int
> > > mlxbf_gige_mdio_probe(struct platform_device *pdev, struct mlxbf_gige
> > *priv)
> > >         snprintf(priv->mdiobus->id, MII_BUS_ID_SIZE, "%s",
> > >                  dev_name(dev));
> > >
> > > +       pm_runtime_set_autosuspend_delay(priv->mdiobus->parent, 100);
> > > +       pm_runtime_use_autosuspend(priv->mdiobus->parent);
> > 
> > Why parent?
> 
> That was just an experiment. I tried priv->dev, same result but I guess that is expected because it is the MAC dev. priv->mdiobus->dev is only set in mdiobus_register which:
> - sets dev struct and calls device_register
> - device_register calls device_pm_init and device_add
> - device_add calls device_pm_add
> - device_pm_check_callbacks sets dev->power.no_pm_callbacks based on if pm_domain/pm_ops were defined or not.
> 
> So I have to call dev_pm_domain_set before mdiobus_register for it to be registered properly. But then, priv->mdiobus->dev is not set up yet so we cannot call dev_pm_domain_set.

You are the first needing this, so i'm not surprised. Please look at
how priv->mdiobus->dev can be made to work. Maybe the
device_register() needs moving into mdiobus_alloc_size()?

	Andrew