From: Vladimir Oltean <olteanv@gmail.com>
To: Gerhard Engleder <gerhard@engleder-embedded.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>,
netdev <netdev@vger.kernel.org>, Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Russell King <linux@armlinux.org.uk>,
Jakub Kicinski <kuba@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH net] Revert "net: phy: Uniform PHY driver access"
Date: Mon, 13 Sep 2021 00:38:55 +0300 [thread overview]
Message-ID: <20210912213855.kxoyfqdyxktax6d3@skbuf> (raw)
In-Reply-To: <CANr-f5wCpcPM+FbeW+x-JmZt0-WmE=b5Ys1Pa_G7p8v3nLyCcQ@mail.gmail.com>
On Sun, Sep 12, 2021 at 10:49:25PM +0200, Gerhard Engleder wrote:
> > This reverts commit 3ac8eed62596387214869319379c1fcba264d8c6.
> >
> > I am not actually sure I follow the patch author's logic, because the
> > change does more than it says on the box, but this patch breaks
> > suspend/resume on NXP LS1028A and probably on any other systems which
> > have PHY devices with no driver bound, because the patch has removed the
> > "!phydev->drv" check without actually explaining why that is fine.
>
> The wrong assumption was that the driver is set for every device during probe
> before suspend. Intention of the patch was only clean up of
> to_phy_driver() usage.
I am not sure why "to_phy_driver" needs cleanup. Au contraire, I think
the PHY library's usage of struct phy_device :: drv is what is strange
and potentially buggy, it is the only subsystem I know of that keeps its
own driver pointer rather than looking at struct device :: driver.
I think this is largely for historical reasons (it has done this since
the first commit), but it looks to me like to_phy_driver could be used
as part of a larger macro called something like phydev_get_drv which
retrieves the phy_driver from the phydev->mdio.dev.driver.
I say it is buggy because when probing fails ("fails" includes things
like -EPROBE_DEFER) it does not even bother to clear phydev->drv back to
NULL, even though the device will not have a driver pointer. There are
also other things which it does not clean up on probe failure, btw, each
with its own interesting side effects.
> > static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
> > {
> > + struct device_driver *drv = phydev->mdio.dev.driver;
> > + struct phy_driver *phydrv = to_phy_driver(drv);
> > struct net_device *netdev = phydev->attached_dev;
> >
> > - if (!phydev->drv->suspend)
> > + if (!drv || !phydrv->suspend)
> > return false;
> >
> > /* PHY not attached? May suspend if the PHY has not already been
>
> I suggest to add the "!phydev->drv" check, but others may know it
> better than me.
So in this case, the difference will be that with your change, a
phy_probe that returns an error code like -EPROBE_DEFER will have the
phydev->drv set, and it will not return false ("may not suspend") quickly,
while the code in its original form will not attempt to suspend that PHY.
The implication is that we may call the ->suspend method of a PHY that
is deferring probe, _before_ the probe has actually succeeded.
To me, making that change and moving the code in yet a third state is
way outside of the scope, which was to restore it to a known working
condition (aka bug fix). If you want to make that change, feel free, I will not.
next prev parent reply other threads:[~2021-09-12 21:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-12 19:28 [RFC PATCH net] Revert "net: phy: Uniform PHY driver access" Vladimir Oltean
2021-09-12 20:49 ` Gerhard Engleder
2021-09-12 21:38 ` Vladimir Oltean [this message]
2021-09-13 18:49 ` Andrew Lunn
2021-09-14 12:06 ` Vladimir Oltean
2021-09-14 14:33 ` Andrew Lunn
2021-09-14 15:15 ` Vladimir Oltean
2021-09-14 16:17 ` Gerhard Engleder
2021-09-14 16:29 ` Andrew Lunn
2021-09-14 17:14 ` Gerhard Engleder
2021-09-14 17:44 ` Vladimir Oltean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210912213855.kxoyfqdyxktax6d3@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=gerhard@engleder-embedded.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox