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

[Asmaa Mnebhi]

 > > > 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.

Thank you.
Asmaa