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 for Android: free password hash cracker in your pocket

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

Message-ID: <20210213001808.GN1463@shell.armlinux.org.uk>
Date:   Sat, 13 Feb 2021 00:18:08 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Michael Walle <michael@...le.cc>
Cc:     Vladimir Oltean <olteanv@...il.com>,
        "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>,
        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:
> 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 ;)

If we start messing around with the configuration of PHYs in that
regard, we could be opening ourselves up for a world of pain...

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

That is a function of the interface mode and the PHY capabilities.

1) if the PHY supports rate adaption, and is programmed for that, then
   the PHY link normally operates at a fixed speed (e.g. 1G for SGMII)
   and the PHY converts to the appropriate speed.

   We don't actually support this per se, since the parameters we give
   to the MAC via mac_link_up() are the media side parameters, not the
   link parameters.

2) if the PHY does not support rate adaption, then the MAC to PHY link
   needs to follow the media speed and duplex. phylink will be in "PHY"
   mode, where it passes the media side negotiation results to the MAC
   just like phylib would, and the MAC should be programmed
   appropriately. In the case of a SGMII link, the link needs to be
   programmed to do the appropriate symbol repetition for 100M and 10M
   speeds. The PHY /should/ do that automatically, but if it doesn't,
   then the PHY also needs to be programmed to conform. (since if
   there's no rate adaption in the PHY, the MAC side and the media side
   must match.)

Hope that helps.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!