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]
Date:   Thu, 25 Apr 2019 17:23:32 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Ong, Boon Leong" <boon.leong.ong@...el.com>
Cc:     "Voon, Weifeng" <weifeng.voon@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Jose Abreu <joabreu@...opsys.com>
Subject: Re: [PATCH 0/7] net: stmmac: enable EHL SGMII

> >> > > This patch-set is to enable Ethernet controller (DW Ethernet QoS and
> >> > > DW Ethernet PCS) with SGMII interface in Elkhart Lake.
> >> >
> >> > Can the hardware also do 1000BaseX?
> >>
> >> Yes, it is able to do 1000BaseX.
> >
> >I Voon
> >
> >That means you should not really hard code it to SGMII. Somebody is
> >going to connect an SFP or an Ethernet switch and want to use
> >1000BaseX.
> 
> Hi Andrew,
> 
> The Ethernet controller consists of two ways to connect to external PHY,
> RGMII and SGMII. The selection is done through soft strap.
> The patch-series is to enable SGMII interface. The DW xPCS IP is
> configured to operate in 1000BASE-X mode. The xPCS IP is external
> connected through internal PHY interface which presents externally
> as SGMII interface. To help illustrate the connection:-
> 
>       <-----------------GBE Controller----------------->|<--External PHY chip-->
> 
>       +----------+                    +----+          +---+                          +-----------------+
>       |   EQoS   | <-GMII->|xPCS|<--> | L1 | <-- SGMII --> | External GbE |
>       |   MAC    |                 |         |       |PHY|                         | PHY Chip        |
>       +----------+                    +----+          +---+                          +-----------------+
>             
> In future, we will submit the changes for the RGMII connection that
> bypasses DW xPCS.  

The ASCII art get messed up somewhere.

What you are implementing looks like:


       <-----------------GBE Controller------------>|<--External PHY chip-->
 
       +----------+                    +----+                 +---+
       |   EQoS   | <-GMII->|xPCS|<--> | L1 | <-- SGMII -->   |PHY|
       |   MAC    |                    |    |                 +---+
       +----------+                    +----+                      

With the Ethernet controller, the MAC connects to the xPCS. Out of the
xPCS you have a SERDES connection, running the SGMII protocol. That
connects to external pins of the SoC. These are then connected to a
copper PHY which also supports SGMII.

What i'm trying to understand is if the following is possible:

       <-----------------GBE Controller------------->|<--External SFP cage/module-->
 
       +----------+                    +----+                   +---+
       |   EQoS   | <-GMII->|xPCS|<--> | L1 | <-- 1000BaseX --> |SPF|
       |   MAC    |                    |    |                   +---+
       +----------+                    +----+                      

Rather than use a Copper PHY, an SFP cage+module is used. The same
SERDES interface is used, but 1000BaseX runs over it.

Generally, an xPCS which can run SGMII can also do 1000BaseX, because
SGMII is just some Cisco Proprietary extensions to 1000BaseX.

If the xPCS can do 1000BaseX over the SERDES, you should not hard code
it to SGMII, but allow it to be configured.

      Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ