[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3251e228-8ca5-4e33-be90-5e262c47722e@lunn.ch>
Date: Thu, 3 Jul 2025 22:49:58 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Asmaa Mnebhi <asmaa@...dia.com>
Cc: "davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
David Thompson <davthompson@...dia.com>
Subject: Re: [PATCH net v1] mlxbf-gige: Support workaround for MDIO GPIO
degradation bug
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
Powered by blists - more mailing lists