Re: [PATCH net-next 1/2] net: phylink: explicitly configure in-band autoneg for PHYs that support it

Am 2021-02-13 01:36, schrieb Vladimir Oltean:

On Fri, Feb 12, 2021 at 11:40:59PM +0100, Michael Walle wrote:

quoted

Am 2021-02-12 18:23, schrieb Vladimir Oltean:

quoted

From: Vladimir Oltean <vladimir.oltean@nxp.com>

Currently Linux has no control over whether a MAC-to-PHY interface uses
in-band signaling or not, even though phylink has the
	managed = "in-band-status";
property which denotes that the MAC expects in-band signaling to be
used.

The problem is really that if the in-band signaling is configurable in
both the PHY and the MAC, there is a risk that they are out of sync
unless phylink manages them both. Most if not all in-band autoneg state
machines follow IEEE 802.3 clause 37, which means that they will not
change the operating mode of the SERDES lane from control to data mode
unless in-band AN completed successfully. Therefore traffic will not
work.

It is particularly unpleasant that currently, we assume that PHYs which
have configurable in-band AN come pre-configured from a prior boot stage
such as U-Boot, because once the bootloader changes, all bets are off.

Fun fact, now it may be the other way around. If the bootloader 
doesn't
configure it and the PHY isn't reset by the hardware, it won't work in
the bootloader after a reboot ;)

My understanding is that this is precisely the reason why the U-Boot
people don't want to support booting from RAM, and want to assume that
the nothing else ran between Power On Reset and the bootloader:
https://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
[ that does make me wonder what they think about ARM TF-A ]

It isn't that easy sometimes. Eg. there might be boards without a proper
reset of the peripherals, maybe the SoC will just generate an internal
reset, whatever. One might conisder that a broken board. But, for
example, on the kontron sl28, we deliberatly chose not to do a PHY
reset (well it is actually configurable) because this will also prevent
WoL by the PHY.

quoted

quoted

Let's introduce a new PHY driver method for configuring in-band autoneg,
and make phylink be its first user. The main PHY library does not call
phy_config_inband_autoneg, because it does not know what to configure it
to. Presumably, non-phylink drivers can also call
phy_config_inband_autoneg
individually.

If you disable aneg between MAC and PHY, what would be the actual 
speed
setting/duplex mode then? I guess it have to match the external speed?

I'm trying this on the AT8031. I've removed 'managed = 
"in-band-status";'
for the PHY. Confirmed that it won't work and then I've implemented 
your
new callback. That will disable the SGMII aneg (which is done via the
BMCR of fiber page if I'm not entirely mistaken); ethernet will then
work again. But only for gigabit. I presume because the speed setting
of the SGMII link is set to gigabit.

Which MAC driver are you testing on?

enetc

Are you saying that it doesn't
force the link to the speed resolved over MDIO and passed to
.phylink_mac_link_up, or that the speed communicated to it is 
incorrect?

That seem to work:

[ 5313.852406] fsl_enetc 0000:00:00.0 gbe0: phy link down 
sgmii/Unknown/Unknown
[ 5313.852414] fsl_enetc 0000:00:00.0 gbe0: Link is Down
[ 5315.900687] fsl_enetc 0000:00:00.0 gbe0: phy link up 
sgmii/100Mbps/Full
[ 5315.916816] fsl_enetc 0000:00:00.0 gbe0: Link is Up - 100Mbps/Full - 
flow control rx/tx

But the Atheros PHY seems to have a problem with the SGMII link
if there is no autoneg.
No matter what I do, I can't get any traffic though if its not
gigabit on the copper side. Unfortunately, I don't have access
to an oscilloscope right now to see whats going on on the SGMII
link.

-michael