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

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46c9b91b8f99605a26fbd7f26d5947b6@walle.cc>
Date:   Sat, 13 Feb 2021 17:53:41 +0100
From:   Michael Walle <michael@...le.cc>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Antoine Tenart <atenart@...nel.org>,
        Quentin Schulz <quentin.schulz@...tlin.com>,
        netdev@...r.kernel.org, Heiner Kallweit <hkallweit1@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Maxim Kochetkov <fido_max@...ox.ru>,
        Bjarni Jonasson <bjarni.jonasson@...rochip.com>,
        Steen Hegelund <steen.hegelund@...rochip.com>,
        UNGLinuxDriver@...rochip.com
Subject: 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:
>> Am 2021-02-12 18:23, schrieb Vladimir Oltean:
>> > From: Vladimir Oltean <vladimir.oltean@....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