From: "Marek Behún" <firstname.lastname@example.org>
To: Russell King - ARM Linux admin <email@example.com>, firstname.lastname@example.org
Cc: email@example.com, firstname.lastname@example.org, email@example.com
Subject: mv88e6xxx: 2500base-x inband AN is broken on Amethyst? what to do?
Date: Wed, 13 Jan 2021 01:18:23 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
it seems that inband AN is broken on Amethyst when on 2500base-x mode.
Even SERDES scripts for Amethyst from Marvell has autonegotiation
disabled for 2500base-x mode. For all the other supported Serdes modes
autonegotiation is enabled in these scripts.
The current implementation in mv88e6390_serdes_pcs_config() enables
autonegotiation if phylink_autoneg_inband(mode) is true:
bmcr = val | BMCR_ANENABLE;
bmcr = val & ~BMCR_ANENABLE;
But for PHY_INTERFACE_MODE_2500BASEX this is broken on Amethyst. The
2500base-x mode seems to work only with autoneg disabled.
The result is that when I connect via a passive SFP cable Amethyst
serdes port with a Peridot serdes port, they will not link. If I
disable autonegotiation on both sides, they will link, though.
What is strange is that if I don't use Peridot, but connect the SFP
directly to Serdes on Armada 3720, where the mvneta driver also enables
autonegotiation for 2500base-x mode, they will link even if Amethyst
does not enable 2500base-x.
Amethyst <-> Peridot
AN - AN - works
AN - AN + does not work
Amethyst <-> Armada 3720 serdes
AN - AN + works
(It is possible that Marvell may find some workaround by touch some
undocumented registers, to solve this. I will try to open a bug
Should we just print an error in the serdes_pcs_config method if inband
autonegotiation is being requested?
phylink's code currently allows connecting SFPs in non MLO_AN_INBAND
mode only for when there is Broadcom BCM84881 PHY inside the SFP (by
method phylink_phy_no_inband() in phylink.c).
I wonder whether we can somehow in a sane way implement code to inform
phylink from the mv88e6xxx driver that inband is not supported for the
specific mode. Maybe the .mac_config/.pcs_config method could return an
error indicating this? Or the mv88e6xxx driver can just print an error
that the mode is not supported, and try to ask the user to disable AN?
That would need implementing this in ethtool for SFP, though.
What do you guys think?
next reply other threads:[~2021-01-13 0:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-13 0:18 Marek Behún [this message]
2021-01-13 4:22 ` mv88e6xxx: 2500base-x inband AN is broken on Amethyst? what to do? Marek Behun
2021-01-13 10:28 ` Russell King - ARM Linux admin
2021-01-13 17:03 ` Marek Behún
2021-01-13 20:08 ` Marek Behún
2021-01-13 21:21 ` Russell King - ARM Linux admin
2021-01-13 21:37 ` Marek Behún
2021-01-13 21:48 ` Russell King - ARM Linux admin
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).