[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210325003035.GJ1463@shell.armlinux.org.uk>
Date: Thu, 25 Mar 2021 00:30:36 +0000
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Marek BehĂșn <kabel@...nel.org>,
netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
"David S . Miller" <davem@...emloft.net>,
Heiner Kallweit <hkallweit1@...il.com>,
Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
pali@...nel.org
Subject: Re: [PATCH net-next 0/2] dt-bindings: define property describing
supported ethernet PHY modes
On Wed, Mar 24, 2021 at 05:11:25PM -0700, Florian Fainelli wrote:
> > And if you use rate matching mode, and the copper side is
> > linked in lower speed (2.5g for example), and the MAC will start
> > sending too many packets, the internal buffer in the PHY is only 16 KB,
> > so it will fill up quickly. So you need pause frames support. But this
> > is broken for speeds <= 1g, according to erratum.
> >
> > So you really want to change modes. The rate matching mode is
> > basically useless.
>
> OK, so whenever there is a link change you are presumably reading the
> mode in which the PHY has been reconfigured to, asking the MAC to
> configured itself appropriately based on that, and if there is no
> intersection, error out?
The 88x3310 already tells the MAC what the interface mode is.
I think what Marc is trying to do is to program the PHY to use the
appropriate _group_ of modes for the MAC connection and then letting
the PHY get on with it, rather than explicitly trying to resolve the
mode (which likely won't work for the 88x3310, since changing the
MAC side mode requires resetting the entire PHY - which will cause
any media side link to be dropped.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists