> -----Original Message----- > From: Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx> > Sent: Monday, December 23, 2019 2:08 PM > To: Madalin Bucur <madalin.bucur@xxxxxxx> > Cc: davem@xxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; andrew@xxxxxxx; > f.fainelli@xxxxxxxxx; hkallweit1@xxxxxxxxx; shawnguo@xxxxxxxxxx; > devicetree@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/6] net: phy: add interface modes for XFI, SFI > > On Thu, Dec 19, 2019 at 06:32:51PM +0000, Madalin Bucur wrote: > > 10GBase-R could be used as a common nominator but just as well 10G and > > remove the rest while we're at it. There are/may be differences in > > features, differences in the way the HW is configured (the most > > important aspect) and one should be able to determine what interface > > type is in use to properly configure the HW. SFI does not have the CDR > > function in the PMD, relying on the PMA signal conditioning vs the XFI > > that requires this in the PMD. > > I've now found a copy of INF-8077i on the net, which seems to be the > document that defines XFI. The definition in there seems to be very > similar to SFI in that it is an electrical specification, not a > protocol specification, and, just like SFI, it defines the electrical > characteristics at the cage, not at the serdes. Therefore, the effects > of the board layout come into play to achieve compliance with XFI. I think we're missing the point here: we need to start from the device tree and that is supposed to describe the board, the hardware, not to configure the software. Please re-read the paragraph above in this key: the device tree needs to describe the HW features, those electrical properties you are discussing above. The fact that we use a certain protocol over it, by choice in software, does not change the HW and it should not change the device tree describing it. > Just like SFI, XFI can be used with multiple different underlying > protocols. I quote: > > "The XFI interface is designed to support SONET OC-192, > IEEE.Std-802.3ae, 10GFC and G.709(OTU-2) applications." > > Therefore, to describe 10GBASE-R as "XFI" is most definitely incorrect. > 10GBASE-R is just _one_ protocol that can be run over XFI, but it is > not the only one. Exactly why the chip to chip interface described by the device tree needs to be xfi not 10GBASE-R, that would really only provide information on the PCS block that we're not featuring in device trees. Here's a rehash of Ethernet nomenclature sourced from [1]: Data rate (R): 1000 → 1000 Mbps or 1 Gbps; Megabit unit is eliminated in the data rate reference 10G → 10 Gbps 10/1G → 10 Gbps downstream, 1 Gbps upstream Modulation type (mTYPE): BASE → Baseband Medium types / wavelength / reach (L): B → Bidirectional optics, with downstream (D) or upstream (U) asymmetric qualifiers C → Twin axial copper D → Parallel single mode (500 m) E → Extra-long optical wavelength λ (1510/1550 nm) / reach (40 km) F → Fiber (2 km) K → Backplane L → Long optical wavelength λ (~1310 nm) / reach (10 km) P → Passive optics, with single or multiple downstream (D) or upstream (U) asymmetric qualifiers, as well as eXternal sourced coding (X) of 4B/5B or 8B/10B RH → Red LED plastic optical fiber with PAM16 coding and different transmit power optics S → Short optical wavelength λ (850 nm) / reach (100 m) T → Twisted pair PCS coding (C): R → scRambled coding (64B/66B) X → eXternal sourced coding (4B/5B, 8B/10B) Number of Lanes (n): Blank space without lane number → defaults as 1-lane 4 → 4-lanes There were no clear names attributed to the interfaced between the blocks that make up the PHY, the PCS, PMA, PMD. When the MII was the clear separation point, it was enough to describe the MII type and that was the initial set of values for the device tree parameter: RGMII, SGMII, XGMII. One can argue that the correct value still is XGMII, as that is the real MAC-PHY interface for 10G. Unfortunately, as this interface does not map to the chip to chip interfaces on our HW, it provides little to no information on the HW. This is the reason I say we need to describe the HW. > As for CDR, INF-8077i says: > > "The XFP module shall include a Signal Conditioner based on CDR (Clock > Data Recovery) technology for complete regeneration." > > Whereas for SFP modules, SFF-8472 revision 11.4 added optional support > for CDR on the modules. > > In any case, the CDR is a matter for the module itself, not for the > host, so it seems that isn't relevent. > > Everything that I've said concerning SFI in my previous email (in date > order), and why we should not be defining that as a phy_interface_t > seems to also apply to XFI from what I've read in INF-8077i, and it > seems my original decision that we should not separately define > XFI and SFI from 10GBASE-R is well founded. > > Given that meeting these electrical characteristics involves the > effects of the board, and it is impractical for a board to switch > between different electrical characteristics at runtime (routing serdes > lanes to both a SFP+ and XFP cage is impractical due to reflections on > unterminated paths) I really don't see any reason why we need two > different phy_interface_t definitions for these. As mentioned, the > difference between XFI and SFI is electrical, and involves the board > layout, which is a platform specific issue. The signal integrity issues you mention are real but there are solutions for that, there are high speed mezzanine connectors that allow that level of flexibility. [1] https://www.synopsys.com/designware-ip/technical-bulletin/ethernet-dwtb-q117.html
