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: <SN6PR11MB313690E7953BF715A8F488D688769@SN6PR11MB3136.namprd11.prod.outlook.com>
Date:   Tue, 6 Apr 2021 09:05:33 +0000
From:   "Voon, Weifeng" <weifeng.voon@...el.com>
To:     Andrew Lunn <andrew@...n.ch>,
        "Sit, Michael Wei Hong" <michael.wei.hong.sit@...el.com>
CC:     "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>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "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

> > > You have a MAC and an PCS in the stmmac IP block. That then has some
> > > sort of SERDES interface, running 1000BaseX, SGMII, SGMII
> > > overclocked at 2.5G or 25000BaseX. Connected to the SERDES you have
> > > a PHY which converts to copper, giving you 2500BaseT.
> > >
> > > You said earlier, that the PHY can only do 2500BaseT. So it should
> > > be the PHY driver which sets supported to 2500BaseT and no other
> > > speeds.
> > >
> > > You should think about when somebody uses this MAC with a different
> > > PHY, one that can do the full range of 10/half through to 2.5G full.
> > > What generally happens is that the PHY performs auto-neg to
> > > determine the link speed. For 10M-1G speeds the PHY will configure
> > > its SERDES interface to SGMII and phylink will ask the PCS to also
> > > be configured to SGMII. If the PHY negotiates 2500BaseT, it will
> > > configure its side of the SERDES to 2500BaseX or SGMII overclocked
> > > at 2.5G. Again, phylink will ask the PCS to match what the PHY is
> > > doing.
> > >
> > > So, where exactly is the limitation in your hardware? PCS or PHY?
> > The limitation in the hardware is at the PCS side where it is either
> > running in SGMII 2.5G or SGMII 1G speeds.
> > When running on SGMII 2.5G speeds, we disable the in-band AN and use
> > 2.5G speed only
> 
> So there is no actual limitation! The MAC should indicate it can do 10Half
> through to 2500BaseT. And you need to listen to PHYLINK and swap the PCS
> between SGMII to overclocked SGMII when it requests.
> 
> PHYLINK will call stmmac_mac_config() and use state->interface to decide
> how to configure the PCS to match what the PHY is doing.
> 
>      Andrew

The limitation is not on the MAC, PCS or the PHY. For Intel mgbe, the
overclocking of 2.5 times clock rate to support 2.5G is only able to be
configured in the BIOS during boot time. Kernel driver has no access to 
modify the clock rate for 1Gbps/2.5G mode. The way to determined the 
current 1G/2.5G mode is by reading a dedicated adhoc register through mdio bus.
In short, after the system boot up, it is either in 1G mode or 2.5G mode 
which not able to be changed on the fly. 

Since the stmmac MAC can pair with any PCS and PHY, I still prefer that we tie
this platform specific limitation with the of MAC. As stmmac does handle platform
specific config/limitation. 

What is your thoughts? 

Weifeng

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ