netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Vladimir Oltean <olteanv@gmail.com>,
	"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>,
	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:41:55 +0100	[thread overview]
Message-ID: <db9f5988d7d135b3588bf9f6a5b10b08@walle.cc> (raw)
In-Reply-To: <20210213001808.GN1463@shell.armlinux.org.uk>

Am 2021-02-13 01:18, schrieb Russell King - ARM Linux admin:
> 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.)

Thanks, but I'm not sure I understand the difference between "rate
adaption" and symbol repetition. The SGMII link is always 1.25Gb,
right? If the media side is 100Mbit it will repeat the symbol 10
times or 100 times in case of 10Mbit. What is "rate adaption" then?

-- 
-michael

  reply	other threads:[~2021-02-13 16:42 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 [this message]
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
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=db9f5988d7d135b3588bf9f6a5b10b08@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 \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).