devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: "Madalin Bucur (OSS)" <madalin.bucur@oss.nxp.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>
Subject: Re: [PATCH 1/6] net: phy: add interface modes for XFI, SFI
Date: Fri, 3 Jan 2020 09:42:04 +0000	[thread overview]
Message-ID: <20200103094204.GA18808@shell.armlinux.org.uk> (raw)
In-Reply-To: <20200103092718.GB25745@shell.armlinux.org.uk>

On Fri, Jan 03, 2020 at 09:27:18AM +0000, Russell King - ARM Linux admin wrote:
> Merely specifying "xfi" does not tell you what you need to do to achieve
> XFI compliance at the point defined in INF8077i.  Plus, XFI can also be
> protocols _other_ than 10GBASE-R.
> 
> Claiming that "XFI" properly defines the interface is utter rubbish. It
> does not. XFI defines the electrical characteristics *only* and not
> the underlying protocol. It is not limited to 10GBASE-R, but includes
> other protocols as well.

Let me quote from INF-8077i, which is the XFP MSA, the document
responsible for defining XFI:

3.1 INTRODUCTION
   XFI signaling is based on high speed low voltage logic, with nominal 100
   Ohms differential impedance and AC coupled in the module. XFI was de-
   veloped with the primary goal of low power and low Electro-Magnetic-In-

   terference (EMI). To satisfy this requirement the nominal differential signal   levels are 500 mV p-p with edge speed control to reduce EMI.

3.2 XFI APPLICATIONS DEFINITION
   The application reference model for XFI, which connects a high speed
   ASIC/SERDES to the XFP module is shown in Figure 4. The XFI interface
   is designed to support SONET OC-192, IEEE.Std-802.3ae, 10GFC and
   G.709(OTU-2) applications. The SERDES is required to meet the applica-
   tion requirements for jitter generation and transfer when interfaced with a
   compliant XFP module through an XFP compliant channel. Modules or

   hosts designed only for 10 Gigabit Ethernet or 10GFC are not required to
   meet more stringent Telecom jitter requirements. XFI supported data
   rates are listed in Table 5. XFP compliant module are not required to sup-
   port all the rates listed in Table 5 in simultaneously.

   Standard                            Description           Nominal Bit Rate     Units
   OC-192/SDH-64                         SONET                     9.95         Gigabaud
   IEEE std-802.3ae             10 Gb/s Ethernet LAN PHY           10.31        Gigabaud
   INCITS/T11 Project 1413-D             10GFC                     10.52        Gigabaud
   ITU G.709(OTU-2)                 OC-192 Over FEC                10.70        Gigabaud
   Emerging                     10Gb/s Ethernet Over G.709         11.09        Gigabaud

So here, we can clearly see that it's possible to run SONET, 10GBASE-R,
10G Fiberchannel, OC-192, and G.709 over XFI, so XFI does not describe
_just_ ethernet. If we're going to be configuring a serdes to output
XFI, we need to know a lot more than just "XFI".

   XFI Compliance points are defined as the following:

   •   A: SerDes transmitter output at ASIC/SerDes package pin on a DUT
       board 3.6 and A.1
   •   B: Host system SerDes output across the host board and connector
       at the Host Compliance Test Card 3.7.1 and A.2
   •   B': XFP transmitter input across the Module Compliance Test Board
       3.8.1 and A.3.
   •   C: Host system input at the Host Compliance Test Card input 3.7.2
       and A.2
   •   C': XFP module output across the Module Compliance Test Board
       3.8.2 and A.3.

   •   D: ASIC/SerDes input package pin on the DUT board 3.6.2 and A.1.

   ASIC/SerDes compliance points are informative.

So the electrical points that count are B, B', C and C'. A and D
are merely "informative".  Hence, compliance with XFI is required
to take the entire platform into account, not just the output of
the serdes/asic.  That means the performance of the PCB needs to
be described in DT if you want to achieve compliance with XFI.
phy_interface_t can't do that.

So, let me re-iterate: neither XFI nor SFI are suitable for
phy_interface_t. XFI defines merely a group of possible protocols
and an electrical specification. It doesn't tell you which of those
protocols you should be using.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

  reply	other threads:[~2020-01-03  9:42 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-19 15:21 [PATCH 0/6] Add PHY connection types for XFI and SFI Madalin Bucur
2019-12-19 15:21 ` [PATCH 1/6] net: phy: add interface modes for XFI, SFI Madalin Bucur
2019-12-19 17:28   ` Russell King - ARM Linux admin
2019-12-19 18:32     ` Madalin Bucur
2019-12-19 19:03       ` Russell King - ARM Linux admin
2019-12-19 21:34         ` Madalin Bucur (OSS)
2019-12-19 21:49           ` Russell King - ARM Linux admin
2019-12-20  7:38             ` Madalin Bucur (OSS)
2019-12-20  9:16               ` Russell King - ARM Linux admin
2019-12-20  9:29                 ` Andrew Lunn
2019-12-20  9:39                   ` Madalin Bucur (OSS)
2019-12-20 10:06                     ` Andrew Lunn
2019-12-23  7:50                       ` Madalin Bucur (OSS)
2019-12-23  8:26                         ` Russell King - ARM Linux admin
2019-12-23  9:57                           ` Madalin Bucur (OSS)
2019-12-23 10:57                             ` Russell King - ARM Linux admin
2019-12-23 12:07       ` Russell King - ARM Linux admin
2019-12-23 13:46         ` Andrew Lunn
2019-12-23 14:30           ` Russell King - ARM Linux admin
2020-01-03  7:01         ` Madalin Bucur (OSS)
2020-01-03  9:27           ` Russell King - ARM Linux admin
2020-01-03  9:42             ` Russell King - ARM Linux admin [this message]
2020-01-03 12:03               ` Madalin Bucur (OSS)
2020-01-03 12:53                 ` Russell King - ARM Linux admin
2020-01-03 13:35                   ` Andrew Lunn
2020-01-03 16:21                     ` Madalin Bucur (OSS)
2020-01-03 17:17                       ` Andrew Lunn
2020-01-06  9:34                         ` Madalin Bucur (OSS)
2020-01-03 15:57                   ` Madalin Bucur (OSS)
2020-01-03 17:19                     ` Russell King - ARM Linux admin
2020-01-06 10:17                       ` Madalin Bucur (OSS)
2020-01-06 13:57                         ` Andrew Lunn
2020-01-06 15:03                           ` Madalin Bucur (OSS)
2019-12-19 15:21 ` [PATCH 2/6] arm64: dts: ls104xardb: set correct PHY interface mode Madalin Bucur
2019-12-19 16:05   ` Andrew Lunn
2019-12-19 18:09     ` Madalin Bucur (OSS)
2019-12-19 15:21 ` [PATCH 3/6] net: fsl/fman: rename IF_MODE_XGMII to IF_MODE_10G Madalin Bucur
2019-12-19 15:21 ` [PATCH 4/6] net: fsl/fman: add support for PHY_INTERFACE_MODE_XFI Madalin Bucur
2019-12-19 15:21 ` [PATCH 5/6] net: fsl/fman: add support for PHY_INTERFACE_MODE_SFI Madalin Bucur
2019-12-19 17:30   ` Russell King - ARM Linux admin
2019-12-19 18:50     ` Madalin Bucur (OSS)
2019-12-19 15:21 ` [PATCH 6/6] net: phy: aquantia: add support for PHY_INTERFACE_MODE_XFI Madalin Bucur

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=20200103094204.GA18808@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=madalin.bucur@oss.nxp.com \
    --cc=netdev@vger.kernel.org \
    --cc=shawnguo@kernel.org \
    /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).