From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Benedikt Spranger <b.spranger@linutronix.de>
Cc: bage@linutronix.de, Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
davem@davemloft.net, netdev@vger.kernel.org
Subject: Re: [PATCH net v2] net: phy: phy_ethtool_ksettings_set: Don't discard phy_start_aneg's return
Date: Mon, 8 Nov 2021 15:40:40 +0000 [thread overview]
Message-ID: <YYlE+JeDwmRsaiec@shell.armlinux.org.uk> (raw)
In-Reply-To: <20211108160653.3d6127df@mitra>
On Mon, Nov 08, 2021 at 04:06:53PM +0100, Benedikt Spranger wrote:
> On Mon, 8 Nov 2021 14:25:48 +0000
> "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
>
> > On Mon, Nov 08, 2021 at 03:18:34PM +0100, bage@linutronix.de wrote:
> > > From: Bastian Germann <bage@linutronix.de>
> > >
> > > Take the return of phy_start_aneg into account so that ethtool will
> > > handle negotiation errors and not silently accept invalid input.
> >
> > I don't think this description is accurate. If we get to call
> > phy_start_aneg() with invalid input, then something has already
> > gone wrong.
> The MDI/MDIX/auto-MDIX settings are not checked before calling
> phy_start_aneg(). If the PHY supports forcing MDI and auto-MDIX, but
> not forcing MDIX _phy_start_aneg() returns a failure, which is silently
> ignored.
That would be very bad if it were to happen.
ksettings_set() would be called. If phy_is_started() returns true, we
trigger the state machine after forcing PHY_UP state. The state machine
calls phy_start_aneg() and gets an error, calling phy_error(), and
the state machine is forced into PHY_HALTED mode with a kernel warning
and stack trace.
That is not nice behaviour for a user.
> Just to be clear: The PHY driver should check the settings and return
> an error before calling phy_ethtool_ksettings_set() ?
The PHY driver doesn't get an opportunity to validate the settings
prior to calling phy_ethtool_ksettings_set() - because the PHY driver
never calls this function. The MAC driver does. However, the MAC driver
doesn't know what the PHY will accept.
This clearly needs to be fixed in phylib.
As a result of your explanation, I now believe your patch to be
fundamentally incorrect given the current state, and it should not be
applied.
We should not accept a call to phy_ethtool_ksettings_set(), modify some
state (setting phydev->advertising/autoneg/master_slave_set/mdix_ctrl/
speed/duplex) and then return an error to the user indicating that the
call failed because we didn't like some parameter - e.g. the mdix_ctrl
value that we've writtent o phydev->mdix_ctrl.
Userspace validation should always happen _prior_ to accepting any
state from userland. If there's an issue with it, the call should fail
without modifying any state.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2021-11-08 15:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-05 15:36 [PATCH] phy: phy_ethtool_ksettings_set: Don't discard phy_start_aneg's return bage
2021-11-05 18:32 ` Andrew Lunn
2021-11-08 14:21 ` Bastian Germann
2021-11-06 21:52 ` Heiner Kallweit
2021-11-08 14:25 ` Bastian Germann
2021-11-10 8:14 ` Heiner Kallweit
2021-11-08 14:18 ` [PATCH net v2] net: " bage
2021-11-08 14:25 ` Russell King (Oracle)
2021-11-08 15:06 ` Benedikt Spranger
2021-11-08 15:40 ` Russell King (Oracle) [this message]
2021-11-08 16:09 ` Andrew Lunn
2021-11-08 16:32 ` Bastian Germann
2021-11-08 17:57 ` Andrew Lunn
2021-11-08 18:01 ` Heiner Kallweit
2021-11-08 18:06 ` Russell King (Oracle)
2021-11-08 19:02 ` Benedikt Spranger
2021-11-08 19:35 ` Heiner Kallweit
2021-11-09 18:29 ` Florian Fainelli
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=YYlE+JeDwmRsaiec@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=b.spranger@linutronix.de \
--cc=bage@linutronix.de \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).