All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Ioana Ciornei <ioana.ciornei@nxp.com>
Cc: linux@armlinux.org.uk, hkallweit1@gmail.com,
	f.fainelli@gmail.com, davem@davemloft.net,
	netdev@vger.kernel.org, alexandru.marginean@nxp.com,
	ruxandra.radulescu@nxp.com
Subject: Re: [PATCH RFC 4/6] dpaa2-mac: add initial driver
Date: Fri, 14 Jun 2019 03:42:23 +0200	[thread overview]
Message-ID: <20190614014223.GD28822@lunn.ch> (raw)
In-Reply-To: <1560470153-26155-5-git-send-email-ioana.ciornei@nxp.com>

> +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;
> +	case PHY_INTERFACE_MODE_QSGMII:
> +	case PHY_INTERFACE_MODE_RGMII:
> +	case PHY_INTERFACE_MODE_RGMII_ID:
> +	case PHY_INTERFACE_MODE_RGMII_RXID:
> +	case PHY_INTERFACE_MODE_RGMII_TXID:
> +		phylink_set(mask, 10baseT_Full);
> +		phylink_set(mask, 100baseT_Full);
> +		phylink_set(mask, 1000baseT_Full);
> +		break;
> +	case PHY_INTERFACE_MODE_USXGMII:
> +		phylink_set(mask, 10baseT_Full);
> +		phylink_set(mask, 100baseT_Full);
> +		phylink_set(mask, 1000baseT_Full);
> +		phylink_set(mask, 10000baseT_Full);
> +		break;
> +	default:
> +		goto empty_set;
> +	}

I think this is wrong. This is about validating what the MAC can
do. The state->interface should not matter. The PHY will indicate what
interface mode should be used when auto-neg has completed. The MAC is
then expected to change its interface to fit.

But lets see what Russell says.

> +static void dpaa2_mac_config(struct phylink_config *config, unsigned int mode,
> +			     const struct phylink_link_state *state)
> +{
> +	struct dpaa2_mac_priv *priv = to_dpaa2_mac_priv(phylink_config);
> +	struct dpmac_link_state *dpmac_state = &priv->state;
> +	struct device *dev = &priv->mc_dev->dev;
> +	int err;
> +
> +	if (state->speed == SPEED_UNKNOWN && state->duplex == DUPLEX_UNKNOWN)
> +		return;
> +
> +	dpmac_state->up = !!state->link;
> +	if (dpmac_state->up) {
> +		dpmac_state->rate = state->speed;
> +
> +		if (!state->duplex)
> +			dpmac_state->options |= DPMAC_LINK_OPT_HALF_DUPLEX;
> +		else
> +			dpmac_state->options &= ~DPMAC_LINK_OPT_HALF_DUPLEX;
> +
> +		if (state->an_enabled)
> +			dpmac_state->options |= DPMAC_LINK_OPT_AUTONEG;
> +		else
> +			dpmac_state->options &= ~DPMAC_LINK_OPT_AUTONEG;

As Russell pointed out, this auto-neg is only valid in a limited
context. The MAC generally does not perform auto-neg. The MAC is only
involved in auto-neg when inband signalling is used between the MAC
and PHY in 802.3z.

As the name says, dpaa2_mac_config is about the MAC.

   Andrew

  reply	other threads:[~2019-06-14  1:42 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 [this message]
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
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=20190614014223.GD28822@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=alexandru.marginean@nxp.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=ioana.ciornei@nxp.com \
    --cc=linux@armlinux.org.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.