From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Ioana Ciornei <ioana.ciornei@nxp.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Alexandru Marginean <alexandru.marginean@nxp.com>,
Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>
Subject: Re: [PATCH RFC 4/6] dpaa2-mac: add initial driver
Date: Fri, 14 Jun 2019 18:03:18 +0100 [thread overview]
Message-ID: <20190614170318.rjn72deumf3eyasr@shell.armlinux.org.uk> (raw)
In-Reply-To: <VI1PR0402MB2800FA7EF554B855F3B90353E0EE0@VI1PR0402MB2800.eurprd04.prod.outlook.com>
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
next prev parent reply other threads:[~2019-06-14 17:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-13 23:55 [PATCH RFC 0/6] DPAA2 MAC Driver Ioana Ciornei
2019-06-13 23:55 ` [PATCH RFC 1/6] net: phy: update the autoneg state in phylink_phy_change Ioana Ciornei
2019-06-13 23:55 ` [PATCH RFC 2/6] dpaa2-eth: add support for new link state APIs Ioana Ciornei
2019-06-14 1:01 ` Andrew Lunn
2019-06-14 14:03 ` Ioana Ciornei
2019-06-13 23:55 ` [PATCH RFC 3/6] dpaa2-mac: add MC API for the DPMAC object Ioana Ciornei
2019-06-14 1:12 ` Andrew Lunn
2019-06-14 14:06 ` Ioana Ciornei
2019-06-17 14:28 ` Andrew Lunn
2019-06-13 23:55 ` [PATCH RFC 4/6] dpaa2-mac: add initial driver Ioana Ciornei
2019-06-14 1:42 ` Andrew Lunn
2019-06-14 9:50 ` Russell King - ARM Linux admin
2019-06-14 16:54 ` Ioana Ciornei
2019-06-14 17:03 ` Russell King - ARM Linux admin [this message]
2019-06-14 14:08 ` Ioana Ciornei
2019-06-14 10:20 ` Russell King - ARM Linux admin
2019-06-14 16:34 ` Ioana Ciornei
2019-06-13 23:55 ` [PATCH RFC 5/6] dpaa2-eth: add autoneg support Ioana Ciornei
2019-06-13 23:55 ` [PATCH RFC 6/6] net: documentation: add MAC/PHY proxy driver documentation Ioana Ciornei
2019-06-14 9:42 ` [PATCH RFC 0/6] DPAA2 MAC Driver Russell King - ARM Linux admin
2019-06-14 15:26 ` Ioana Ciornei
2019-06-17 14:46 ` Andrew Lunn
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=20190614170318.rjn72deumf3eyasr@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=alexandru.marginean@nxp.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=ioana.ciornei@nxp.com \
--cc=netdev@vger.kernel.org \
--cc=ruxandra.radulescu@nxp.com \
/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).