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: <20210213003641.gybb6gstjpkcwr6z@skbuf>
Date:   Sat, 13 Feb 2021 02:36:41 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Michael Walle <michael@...le.cc>
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

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 ]

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