netdev - phylink / mv8e6xxx and SGMII aneg not working, link doesn't come up

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 27 Feb 2019 22:25:54 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Russell King - ARM Linux <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: phylink / mv8e6xxx and SGMII aneg not working, link doesn't come up

For the ones who don't know my story yet:
I have a Marvell 88E6390 switch with a Clause 45 PHY connected via
SGMII to port 9. For other reasons I limit the PHY to 100Mbps currently.
DT says: managed = "in-band-status"
Driver is mv8e6xxx + phylink.
Problem is that the link doesn't come up. Debugging resulted in:

PHY establishes link to link partner (100Mbps, FD) and fires the
"link up" interrupt. The "link up" is also properly transmitted via
SGMII in-band signalling and fires the SERDES interrupt in mv8e6xxx.
Problem is that the in-band transmitted values for speed and duplex
don't show up anywhere. And phylink_resolve() doesn't even print
the link-up message.

First question: Both, PHY and SERDES interrupt, try to do the same
thing: they eventually call phylink_run_resolve(). Is this correct?

I have some problems with understanding the code for MLO_AN_INBAND
in phylink_resolve(). Maybe also something is missing there for
proper in-band aneg support.

First we get the mac state (which is link down, 10Mbps, HD in my case).
Then the link state is calculated as "mac link up" && "phy link up".
This results in "link down", because mac link is down and phy link is
up. This logic isn't clear to me. How is the "link up" info supposed
to ever reach the mac?
We're reading the port status, but IMO we want to set it based on the
auto-negotiated settings we get from the PHY.

Later pause settings and possibly changed interface mode are
propagated to the mac. But no word about speed and duplex.

Via "some callback" "some code" should read the in-band-transmitted
speed and duplex values from the SGMII port and use them to configure
the mac. Is this simply missing or do I miss something?

Heiner