[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210407130006.GH1463@shell.armlinux.org.uk>
Date: Wed, 7 Apr 2021 14:00:07 +0100
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: "Voon, Weifeng" <weifeng.voon@...el.com>,
"Sit, Michael Wei Hong" <michael.wei.hong.sit@...el.com>,
"peppe.cavallaro@...com" <peppe.cavallaro@...com>,
"alexandre.torgue@...com" <alexandre.torgue@...com>,
"joabreu@...opsys.com" <joabreu@...opsys.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"kuba@...nel.org" <kuba@...nel.org>,
"mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>,
"Ong, Boon Leong" <boon.leong.ong@...el.com>,
"qiangqing.zhang@....com" <qiangqing.zhang@....com>,
"Wong, Vee Khee" <vee.khee.wong@...el.com>,
"fugang.duan@....com" <fugang.duan@....com>,
"Chuah, Kim Tatt" <kim.tatt.chuah@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-stm32@...md-mailman.stormreply.com"
<linux-stm32@...md-mailman.stormreply.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"hkallweit1@...il.com" <hkallweit1@...il.com>
Subject: Re: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for stmmac
On Wed, Apr 07, 2021 at 02:44:39PM +0200, Andrew Lunn wrote:
> > Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell
> > multi-gige PHY can do rate adaption right?
>
> The Marvell/Marvell multi-gige PHY can also do rate
> adaptation. Marvell buying Aquantia made naming messy :-(
> I should probably use part numbers.
>
> > Hence, we still need to take care of others PHYs.
>
> Yes, it just makes working around the broken design harder if you want
> to get the most out of the hardware.
FYI, we really need to come up with a good solution to the rate
adaption issue. What we have today really is not good.
For example, take a MAC that supports only 2500base-X connected to a
PHY that does rate adaption from 2500base-X to media speed.
So, the PHY could be capable of 10, 100, 1G and 2.5G media speeds,
and would advertise those in its supported mask. The MAC however
would only report (via the validate callback) support for 2.5G speed
because that's all that 2500base-X supports.
What we really want when a rate adapting capable PHY is connected is
to ignore what ethtool link modes the MAC supports beyond "does it
support this interface type" and just use the PHY supported mask.
However, that's another property of the PHY that we need to know from
phylib, and it's not clear when that property should be made available.
As we know from Marvell PHYs, it depends on the configurable MAC_TYPE
setting, so could only be available once we've selected an interface
mode for the PHY. On the other hand, we might need to know what
interface mode(s) are available from the PHY and MAC to select an
appropriate mode.
This is not easy problems to overcome; I have had some patches for some
time which allow some combination of MAC and PHY to advertise which
interface mode(s) they support but I haven't been entirely happy with
them to push them upstream - and it would be another phylink API change
which means having to maintain the new and old code until everything
has been updated (thereby making stuff a lot more complex.) After the
last round of phylink API updates and the hostility from people over
that, this is a big demotivating factor.
--
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