netdev - Re: [PATCH RFC 4/6] dpaa2-mac: add initial driver

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: <20190614170318.rjn72deumf3eyasr@shell.armlinux.org.uk>
Date:   Fri, 14 Jun 2019 18:03:18 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Ioana Ciornei <ioana.ciornei@....com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Ioana Ciocoi Radulescu <ruxandra.radulescu@....com>
Subject: Re: [PATCH RFC 4/6] dpaa2-mac: add initial driver

On Fri, Jun 14, 2019 at 04:54:56PM +0000, Ioana Ciornei wrote:
> > Subject: Re: [PATCH RFC 4/6] dpaa2-mac: add initial driver
> > 
> > On Fri, Jun 14, 2019 at 03:42:23AM +0200, Andrew Lunn wrote:
> > > > +static phy_interface_t phy_mode(enum dpmac_eth_if eth_if) {
> > > > +	switch (eth_if) {
> > > > +	case DPMAC_ETH_IF_RGMII:
> > > > +		return PHY_INTERFACE_MODE_RGMII;
> > >
> > > So the MAC cannot insert RGMII delays? I didn't see anything in the
> > > PHY object about configuring the delays. Does the PCB need to add
> > > delays via squiggles in the tracks?
> > >
> > > > +static void dpaa2_mac_validate(struct phylink_config *config,
> > > > +			       unsigned long *supported,
> > > > +			       struct phylink_link_state *state) {
> > > > +	struct dpaa2_mac_priv *priv = to_dpaa2_mac_priv(phylink_config);
> > > > +	struct dpmac_link_state *dpmac_state = &priv->state;
> > > > +	__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> > > > +
> > > > +	phylink_set(mask, Autoneg);
> > > > +	phylink_set_port_modes(mask);
> > > > +
> > > > +	switch (state->interface) {
> > > > +	case PHY_INTERFACE_MODE_10GKR:
> > > > +		phylink_set(mask, 10baseT_Full);
> > > > +		phylink_set(mask, 100baseT_Full);
> > > > +		phylink_set(mask, 1000baseT_Full);
> > > > +		phylink_set(mask, 10000baseT_Full);
> > > > +		break;
> > 
> > How does 10GBASE-KR mode support these lesser speeds - 802.3 makes no
> > provision for slower speeds for a 10GBASE-KR link, it is a fixed speed link.  I
> > don't see any other possible phy interface mode supported that would allow
> > for the 1G, 100M and 10M speeds (i.o.w. SGMII).  If SGMII is not supported,
> > then how do you expect these other speeds to work?
> > 
> > Does your PHY do speed conversion - if so, we need to come up with a much
> > better way of handling that (we need phylib to indicate that the PHY is so
> > capable.)
> 
> These are PHYs connected using an XFI interface that indeed can operate at lower
> speeds and are capable of rate adaptation using pause frames.
> 
> Also, I've used PHY_INTERFACE_MODE_10GKR since a dedicated XFI mode is not available.

XFI is basically what that interface mode for - there's a bunch of
different descriptions for it which seems to depend on the module -
SFI for SFP, XFI for XFP, but essentially it's just 10GBASE-R over a
single serdes lane.

My inclusion of the K in there may not be completely correct as that
is for backplane 10GBASE-R connections, but the public information
available is very limited and incomplete.

-- 
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