From: Vladimir Oltean <olteanv@gmail.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
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 22:29:02 +0200 [thread overview]
Message-ID: <20211206202902.u4h6gn7epjysd7re@skbuf> (raw)
In-Reply-To: <Ya5wFvijUQVwvat7@shell.armlinux.org.uk>
On Mon, Dec 06, 2021 at 08:18:30PM +0000, Russell King (Oracle) wrote:
> 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.
I can understand between MLO_AN_INBAND and MLO_AN_PHY, but isn't it
reasonable that a "fixed" link is "fixed" and doesn't change?
After all, it's in the name. The mv88e6xxx code doesn't appear
necessarily problematic. This issue could crop up again and again with
other drivers.
next prev parent reply other threads:[~2021-12-06 20:29 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)
2021-12-06 20:29 ` Vladimir Oltean [this message]
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=20211206202902.u4h6gn7epjysd7re@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=kernel@collabora.com \
--cc=linux@armlinux.org.uk \
--cc=martyn.welch@collabora.com \
--cc=netdev@vger.kernel.org \
--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).