netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Antoine Tenart <atenart@kernel.org>,
	Quentin Schulz <quentin.schulz@bootlin.com>,
	netdev@vger.kernel.org, Heiner Kallweit <hkallweit1@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	Ioana Ciornei <ioana.ciornei@nxp.com>,
	Maxim Kochetkov <fido_max@inbox.ru>,
	Bjarni Jonasson <bjarni.jonasson@microchip.com>,
	Steen Hegelund <steen.hegelund@microchip.com>,
	UNGLinuxDriver@microchip.com
Subject: Re: [PATCH net-next 1/2] net: phylink: explicitly configure in-band autoneg for PHYs that support it
Date: Sat, 13 Feb 2021 17:53:41 +0100	[thread overview]
Message-ID: <46c9b91b8f99605a26fbd7f26d5947b6@walle.cc> (raw)
In-Reply-To: <20210213003641.gybb6gstjpkcwr6z@skbuf>

Am 2021-02-13 01:36, schrieb Vladimir Oltean:
> On Fri, Feb 12, 2021 at 11:40:59PM +0100, Michael Walle wrote:
>> Am 2021-02-12 18:23, schrieb Vladimir Oltean:
>> > 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.

>> > 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

  reply	other threads:[~2021-02-13 16:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-12 17:23 [PATCH net-next 0/2] Let phylink manage in-band AN for the PHY Vladimir Oltean
2021-02-12 17:23 ` [PATCH net-next 1/2] net: phylink: explicitly configure in-band autoneg for PHYs that support it Vladimir Oltean
2021-02-12 22:40   ` Michael Walle
2021-02-13  0:18     ` Russell King - ARM Linux admin
2021-02-13 16:41       ` Michael Walle
2021-02-13 16:59         ` Andrew Lunn
2021-02-13 17:06         ` Russell King - ARM Linux admin
2021-02-13  0:36     ` Vladimir Oltean
2021-02-13 16:53       ` Michael Walle [this message]
2021-02-13 17:09         ` Michael Walle
2021-02-13 18:56           ` Vladimir Oltean
2021-02-13 19:57             ` Michael Walle
2021-02-13 20:12               ` Vladimir Oltean
2021-02-13 20:16               ` Russell King - ARM Linux admin
2021-02-14 10:35   ` Russell King - ARM Linux admin
2021-02-14 11:10     ` Vladimir Oltean
2021-02-14 13:18       ` Russell King - ARM Linux admin
2021-02-12 17:23 ` [PATCH net-next 2/2] net: phy: mscc: configure in-band auto-negotiation for VSC8514 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=46c9b91b8f99605a26fbd7f26d5947b6@walle.cc \
    --to=michael@walle.cc \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=atenart@kernel.org \
    --cc=bjarni.jonasson@microchip.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=fido_max@inbox.ru \
    --cc=hkallweit1@gmail.com \
    --cc=ioana.ciornei@nxp.com \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=quentin.schulz@bootlin.com \
    --cc=steen.hegelund@microchip.com \
    --subject='Re: [PATCH net-next 1/2] net: phylink: explicitly configure in-band autoneg for PHYs that support it' \
    /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

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).