From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Martyn Welch <martyn.welch@collabora.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
netdev@vger.kernel.org, kernel@collabora.com
Subject: Re: mv88e6240 configuration broken for B850v3
Date: Mon, 6 Dec 2021 20:18:30 +0000 [thread overview]
Message-ID: <Ya5wFvijUQVwvat7@shell.armlinux.org.uk> (raw)
In-Reply-To: <20211206200111.3n4mtfz25fglhw4y@skbuf>
On Mon, Dec 06, 2021 at 10:01:11PM +0200, Vladimir Oltean wrote:
> On Mon, Dec 06, 2021 at 08:53:46PM +0100, Andrew Lunn wrote:
> > So i suspect something is missing when phylink sometime later does
> > bring the interface up. It is not fully undoing what this down
> > does. Maybe enable the dev_dbg() in mv88e6xxx_port_set_link() and see
> > what value it has in both the good and bad case?
>
> Andrew, here is mv88e6xxx_mac_link_down():
>
> if (((!mv88e6xxx_phy_is_internal(ds, port) &&
> !mv88e6xxx_port_ppu_updates(chip, port)) ||
> mode == MLO_AN_FIXED) && ops->port_sync_link)
> err = ops->port_sync_link(chip, port, mode, false);
>
> and here is mv88e6xxx_mac_link_up():
>
> if ((!mv88e6xxx_phy_is_internal(ds, port) &&
> !mv88e6xxx_port_ppu_updates(chip, port)) ||
> mode == MLO_AN_FIXED) {
> (...)
> if (ops->port_sync_link)
> err = ops->port_sync_link(chip, port, mode, true);
>
> This is the CPU port from Martyn's device tree:
>
> port@4 {
> reg = <4>;
> label = "cpu";
> ethernet = <&switch_nic>;
> phy-handle = <&switchphy4>;
> };
>
> It has an internal PHY, so mv88e6xxx_phy_is_internal() will return true.
> True negated is false, so the AND with the other PPU condition is always
> false. BUT: the logic is: "force the link IF it doesn't have an internal
> PHY OR it is a fixed link".
>
> DSA fabricates a mv88e6xxx_mac_link_down call with MLO_AN_FIXED. So
> ->port_sync_link is called with false even if the PHY is internal, due
> to the right hand operand to the || operator.
>
> Then the real phylink, not the impersonator, comes along and calls
> mv88e6xxx_mac_link_up with MLO_AN_PHY. The same check is now not
> satisfied, because the input data has changed!
>
> If we're going to impersonate phylink we could at least provide the same
> arguments as phylink will.
What is going on here in terms of impersonation is entirely reasonable.
The only things in this respect that phylink guarantees are:
1) The MAC/PCS configuration will not be substantially reconfigured
unless a call to mac_link_down() was made if a call to mac_link_up()
was previously made.
2) The arguments to mac_link_down() will be the same as the preceeding
mac_link_up() call - in other words, the "mode" and "interface".
Phylink does *not* guarantee that a call to mac_link_up() or
mac_config() will have the same "mode" as a preceeding call to
mac_link_down(), in the same way that "interface" is not guaranteed.
This has been true for as long as we've had SFPs that need to switch
between MLO_AN_INBAND and MLO_AN_PHY - e.g. because the PHY doesn't
supply in-band information.
So, this has uncovered a latent bug in the Marvell DSA code - and
that is that mac_config() needs to take care of the forcing state
after completing its configuration as I suggested in my previous
reply.
There is also the question whether the automatic fetching of PHY
status information by the hardware should be regarded as a form of
in-band by phylink, even though it isn't true in-band - but from
the software point of view, the PPU's automatic fetching is not
materially different from what happens with SGMII.
--
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-12-06 20:18 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-03 9:06 mv88e6240 configuration broken for B850v3 Martyn Welch
2021-12-03 16:25 ` Andrew Lunn
2021-12-06 17:44 ` Martyn Welch
2021-12-06 18:26 ` Martyn Welch
2021-12-06 18:31 ` Vladimir Oltean
2021-12-06 18:37 ` Martyn Welch
2021-12-06 18:50 ` Vladimir Oltean
2021-12-06 19:24 ` Martyn Welch
2021-12-06 19:37 ` Vladimir Oltean
2021-12-06 19:53 ` Andrew Lunn
2021-12-06 20:01 ` Vladimir Oltean
2021-12-06 20:18 ` Russell King (Oracle) [this message]
2021-12-06 20:29 ` Vladimir Oltean
2021-12-07 14:09 ` Andrew Lunn
2021-12-06 21:44 ` Vladimir Oltean
2021-12-06 22:13 ` Russell King (Oracle)
2021-12-06 20:07 ` Russell King (Oracle)
2021-12-06 20:23 ` Vladimir Oltean
2021-12-06 20:51 ` Russell King (Oracle)
2021-12-06 21:13 ` Vladimir Oltean
2021-12-06 21:27 ` Russell King (Oracle)
2021-12-06 21:49 ` Russell King (Oracle)
2021-12-06 23:27 ` Vladimir Oltean
2021-12-07 0:58 ` Russell King (Oracle)
2021-12-07 13:24 ` Vladimir Oltean
2021-12-07 13:59 ` Russell King (Oracle)
2021-12-07 14:37 ` Vladimir Oltean
2021-12-07 14:53 ` Russell King (Oracle)
2021-12-06 21:51 ` Vladimir Oltean
2021-12-06 22:17 ` Andrew Lunn
2021-12-06 22:22 ` Russell King (Oracle)
2021-12-06 23:44 ` Vladimir Oltean
2021-12-07 2:06 ` Andrew Lunn
2021-12-07 12:48 ` 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=Ya5wFvijUQVwvat7@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=kernel@collabora.com \
--cc=martyn.welch@collabora.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=vivien.didelot@gmail.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;
as well as URLs for NNTP newsgroup(s).