2019-06-11 16:33:12

by Jose Abreu

[permalink] [raw]
Subject: [PATCH net-next 0/3] net: stmmac: Convert to phylink

[ Hope this diff looks better (generated with --minimal) ]

This converts stmmac to use phylink. Besides the code redution this will
allow to gain more flexibility.

Cc: Joao Pinto <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Giuseppe Cavallaro <[email protected]>
Cc: Alexandre Torgue <[email protected]>
Cc: Russell King <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Heiner Kallweit <[email protected]>

Jose Abreu (3):
net: stmmac: Prepare to convert to phylink
net: stmmac: Start adding phylink support
net: stmmac: Convert to phylink and remove phylib logic

drivers/net/ethernet/stmicro/stmmac/Kconfig | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +-
.../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 391 ++++++++----------
.../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +-
5 files changed, 190 insertions(+), 313 deletions(-)

--
2.21.0


2019-06-11 16:37:34

by Jose Abreu

[permalink] [raw]
Subject: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic

Convert everything to phylink.

Signed-off-by: Jose Abreu <[email protected]>
Cc: Joao Pinto <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Giuseppe Cavallaro <[email protected]>
Cc: Alexandre Torgue <[email protected]>
Cc: Russell King <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Heiner Kallweit <[email protected]>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 2 -
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 -
.../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 364 ++++++------------
.../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +-
5 files changed, 132 insertions(+), 339 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index cf0c9f4f347a..c43e2da4e7e3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -3,7 +3,6 @@ config STMMAC_ETH
tristate "STMicroelectronics 10/100/1000/EQOS Ethernet driver"
depends on HAS_IOMEM && HAS_DMA
select MII
- select PHYLIB
select PHYLINK
select CRC32
imply PTP_1588_CLOCK
@@ -42,7 +41,6 @@ if STMMAC_PLATFORM

config DWMAC_DWC_QOS_ETH
tristate "Support for snps,dwc-qos-ethernet.txt DT binding."
- select PHYLIB
select CRC32
select MII
depends on OF && HAS_DMA
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index b8386778f6c6..15523a4546f1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -24,7 +24,6 @@

#include <linux/clk.h>
#include <linux/stmmac.h>
-#include <linux/phy.h>
#include <linux/phylink.h>
#include <linux/pci.h>
#include "common.h"
@@ -148,9 +147,7 @@ struct stmmac_priv {
/* Generic channel for NAPI */
struct stmmac_channel channel[STMMAC_CH_MAX];

- bool oldlink;
int speed;
- int oldduplex;
unsigned int flow_ctrl;
unsigned int pause;
struct mii_bus *mii;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index cec51ba34296..7729aa555a19 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -22,7 +22,7 @@
#include <linux/ethtool.h>
#include <linux/interrupt.h>
#include <linux/mii.h>
-#include <linux/phy.h>
+#include <linux/phylink.h>
#include <linux/net_tstamp.h>
#include <asm/io.h>

@@ -274,7 +274,6 @@ static int stmmac_ethtool_get_link_ksettings(struct net_device *dev,
struct ethtool_link_ksettings *cmd)
{
struct stmmac_priv *priv = netdev_priv(dev);
- struct phy_device *phy = dev->phydev;

if (priv->hw->pcs & STMMAC_PCS_RGMII ||
priv->hw->pcs & STMMAC_PCS_SGMII) {
@@ -353,18 +352,7 @@ static int stmmac_ethtool_get_link_ksettings(struct net_device *dev,
return 0;
}

- if (phy == NULL) {
- pr_err("%s: %s: PHY is not registered\n",
- __func__, dev->name);
- return -ENODEV;
- }
- if (!netif_running(dev)) {
- pr_err("%s: interface is disabled: we cannot track "
- "link speed / duplex setting\n", dev->name);
- return -EBUSY;
- }
- phy_ethtool_ksettings_get(phy, cmd);
- return 0;
+ return phylink_ethtool_ksettings_get(priv->phylink, cmd);
}

static int
@@ -372,8 +360,6 @@ stmmac_ethtool_set_link_ksettings(struct net_device *dev,
const struct ethtool_link_ksettings *cmd)
{
struct stmmac_priv *priv = netdev_priv(dev);
- struct phy_device *phy = dev->phydev;
- int rc;

if (priv->hw->pcs & STMMAC_PCS_RGMII ||
priv->hw->pcs & STMMAC_PCS_SGMII) {
@@ -397,9 +383,7 @@ stmmac_ethtool_set_link_ksettings(struct net_device *dev,
return 0;
}

- rc = phy_ethtool_ksettings_set(phy, cmd);
-
- return rc;
+ return phylink_ethtool_ksettings_set(priv->phylink, cmd);
}

static u32 stmmac_ethtool_getmsglevel(struct net_device *dev)
@@ -443,6 +427,13 @@ static void stmmac_ethtool_gregs(struct net_device *dev,
NUM_DWMAC1000_DMA_REGS * 4);
}

+static int stmmac_nway_reset(struct net_device *dev)
+{
+ struct stmmac_priv *priv = netdev_priv(dev);
+
+ return phylink_ethtool_nway_reset(priv->phylink);
+}
+
static void
stmmac_get_pauseparam(struct net_device *netdev,
struct ethtool_pauseparam *pause)
@@ -450,28 +441,13 @@ stmmac_get_pauseparam(struct net_device *netdev,
struct stmmac_priv *priv = netdev_priv(netdev);
struct rgmii_adv adv_lp;

- pause->rx_pause = 0;
- pause->tx_pause = 0;
-
if (priv->hw->pcs && !stmmac_pcs_get_adv_lp(priv, priv->ioaddr, &adv_lp)) {
pause->autoneg = 1;
if (!adv_lp.pause)
return;
} else {
- if (!linkmode_test_bit(ETHTOOL_LINK_MODE_Pause_BIT,
- netdev->phydev->supported) ||
- !linkmode_test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
- netdev->phydev->supported))
- return;
+ phylink_ethtool_get_pauseparam(priv->phylink, pause);
}
-
- pause->autoneg = netdev->phydev->autoneg;
-
- if (priv->flow_ctrl & FLOW_RX)
- pause->rx_pause = 1;
- if (priv->flow_ctrl & FLOW_TX)
- pause->tx_pause = 1;
-
}

static int
@@ -479,39 +455,16 @@ stmmac_set_pauseparam(struct net_device *netdev,
struct ethtool_pauseparam *pause)
{
struct stmmac_priv *priv = netdev_priv(netdev);
- u32 tx_cnt = priv->plat->tx_queues_to_use;
- struct phy_device *phy = netdev->phydev;
- int new_pause = FLOW_OFF;
struct rgmii_adv adv_lp;

if (priv->hw->pcs && !stmmac_pcs_get_adv_lp(priv, priv->ioaddr, &adv_lp)) {
pause->autoneg = 1;
if (!adv_lp.pause)
return -EOPNOTSUPP;
+ return 0;
} else {
- if (!linkmode_test_bit(ETHTOOL_LINK_MODE_Pause_BIT,
- phy->supported) ||
- !linkmode_test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
- phy->supported))
- return -EOPNOTSUPP;
+ return phylink_ethtool_set_pauseparam(priv->phylink, pause);
}
-
- if (pause->rx_pause)
- new_pause |= FLOW_RX;
- if (pause->tx_pause)
- new_pause |= FLOW_TX;
-
- priv->flow_ctrl = new_pause;
- phy->autoneg = pause->autoneg;
-
- if (phy->autoneg) {
- if (netif_running(netdev))
- return phy_start_aneg(phy);
- }
-
- stmmac_flow_ctrl(priv, priv->hw, phy->duplex, priv->flow_ctrl,
- priv->pause, tx_cnt);
- return 0;
}

static void stmmac_get_ethtool_stats(struct net_device *dev,
@@ -549,7 +502,7 @@ static void stmmac_get_ethtool_stats(struct net_device *dev,
}
}
if (priv->eee_enabled) {
- int val = phy_get_eee_err(dev->phydev);
+ int val = phylink_get_eee_err(priv->phylink);
if (val)
priv->xstats.phy_eee_wakeup_error_n = val;
}
@@ -694,7 +647,7 @@ static int stmmac_ethtool_op_get_eee(struct net_device *dev,
edata->eee_active = priv->eee_active;
edata->tx_lpi_timer = priv->tx_lpi_timer;

- return phy_ethtool_get_eee(dev->phydev, edata);
+ return phylink_ethtool_get_eee(priv->phylink, edata);
}

static int stmmac_ethtool_op_set_eee(struct net_device *dev,
@@ -715,7 +668,7 @@ static int stmmac_ethtool_op_set_eee(struct net_device *dev,
return -EOPNOTSUPP;
}

- ret = phy_ethtool_set_eee(dev->phydev, edata);
+ ret = phylink_ethtool_set_eee(priv->phylink, edata);
if (ret)
return ret;

@@ -892,7 +845,7 @@ static const struct ethtool_ops stmmac_ethtool_ops = {
.get_regs = stmmac_ethtool_gregs,
.get_regs_len = stmmac_ethtool_get_regs_len,
.get_link = ethtool_op_get_link,
- .nway_reset = phy_ethtool_nway_reset,
+ .nway_reset = stmmac_nway_reset,
.get_pauseparam = stmmac_get_pauseparam,
.set_pauseparam = stmmac_set_pauseparam,
.self_test = stmmac_selftest_run,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e2e69cb08fef..ad007d8bf9d7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -328,21 +328,6 @@ static inline u32 stmmac_rx_dirty(struct stmmac_priv *priv, u32 queue)
return dirty;
}

-/**
- * stmmac_hw_fix_mac_speed - callback for speed selection
- * @priv: driver private structure
- * Description: on some platforms (e.g. ST), some HW system configuration
- * registers have to be set according to the link speed negotiated.
- */
-static inline void stmmac_hw_fix_mac_speed(struct stmmac_priv *priv)
-{
- struct net_device *ndev = priv->dev;
- struct phy_device *phydev = ndev->phydev;
-
- if (likely(priv->plat->fix_mac_speed))
- priv->plat->fix_mac_speed(priv->plat->bsp_priv, phydev->speed);
-}
-
/**
* stmmac_enable_eee_mode - check and enter in LPI mode
* @priv: driver private structure
@@ -406,14 +391,7 @@ static void stmmac_eee_ctrl_timer(struct timer_list *t)
*/
bool stmmac_eee_init(struct stmmac_priv *priv)
{
- struct net_device *ndev = priv->dev;
- int interface = priv->plat->interface;
- bool ret = false;
-
- if ((interface != PHY_INTERFACE_MODE_MII) &&
- (interface != PHY_INTERFACE_MODE_GMII) &&
- !phy_interface_mode_is_rgmii(interface))
- goto out;
+ int tx_lpi_timer = priv->tx_lpi_timer;

/* Using PCS we cannot dial with the phy registers at this stage
* so we do not support extra feature like EEE.
@@ -421,52 +399,32 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
if ((priv->hw->pcs == STMMAC_PCS_RGMII) ||
(priv->hw->pcs == STMMAC_PCS_TBI) ||
(priv->hw->pcs == STMMAC_PCS_RTBI))
- goto out;
-
- /* MAC core supports the EEE feature. */
- if (priv->dma_cap.eee) {
- int tx_lpi_timer = priv->tx_lpi_timer;
-
- /* Check if the PHY supports EEE */
- if (phy_init_eee(ndev->phydev, 1)) {
- /* To manage at run-time if the EEE cannot be supported
- * anymore (for example because the lp caps have been
- * changed).
- * In that case the driver disable own timers.
- */
- mutex_lock(&priv->lock);
- if (priv->eee_active) {
- netdev_dbg(priv->dev, "disable EEE\n");
- del_timer_sync(&priv->eee_ctrl_timer);
- stmmac_set_eee_timer(priv, priv->hw, 0,
- tx_lpi_timer);
- }
- priv->eee_active = 0;
- mutex_unlock(&priv->lock);
- goto out;
- }
- /* Activate the EEE and start timers */
- mutex_lock(&priv->lock);
- if (!priv->eee_active) {
- priv->eee_active = 1;
- timer_setup(&priv->eee_ctrl_timer,
- stmmac_eee_ctrl_timer, 0);
- mod_timer(&priv->eee_ctrl_timer,
- STMMAC_LPI_T(eee_timer));
-
- stmmac_set_eee_timer(priv, priv->hw,
- STMMAC_DEFAULT_LIT_LS, tx_lpi_timer);
- }
- /* Set HW EEE according to the speed */
- stmmac_set_eee_pls(priv, priv->hw, ndev->phydev->link);
+ return false;

- ret = true;
- mutex_unlock(&priv->lock);
+ /* Check if MAC core supports the EEE feature. */
+ if (!priv->dma_cap.eee)
+ return false;
+
+ mutex_lock(&priv->lock);

- netdev_dbg(priv->dev, "Energy-Efficient Ethernet initialized\n");
+ /* Check if it needs to be deactivated */
+ if (!priv->eee_active && priv->eee_enabled) {
+ netdev_dbg(priv->dev, "disable EEE\n");
+ del_timer_sync(&priv->eee_ctrl_timer);
+ stmmac_set_eee_timer(priv, priv->hw, 0, tx_lpi_timer);
+ return false;
}
-out:
- return ret;
+
+ if (priv->eee_active && !priv->eee_enabled) {
+ timer_setup(&priv->eee_ctrl_timer, stmmac_eee_ctrl_timer, 0);
+ mod_timer(&priv->eee_ctrl_timer, STMMAC_LPI_T(eee_timer));
+ stmmac_set_eee_timer(priv, priv->hw, STMMAC_DEFAULT_LIT_LS,
+ tx_lpi_timer);
+ }
+
+ mutex_unlock(&priv->lock);
+ netdev_dbg(priv->dev, "Energy-Efficient Ethernet initialized\n");
+ return true;
}

/* stmmac_get_tx_hwtstamp - get HW TX timestamps
@@ -882,54 +840,42 @@ static int stmmac_mac_link_state(struct phylink_config *config,
return -EOPNOTSUPP;
}

-static void stmmac_mac_config(struct net_device *dev)
+static void stmmac_mac_config(struct phylink_config *config, unsigned int mode,
+ const struct phylink_link_state *state)
{
- struct stmmac_priv *priv = netdev_priv(dev);
- struct phy_device *phydev = dev->phydev;
+ struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
u32 ctrl;

ctrl = readl(priv->ioaddr + MAC_CTRL_REG);
+ ctrl &= ~priv->hw->link.speed_mask;

- if (phydev->speed != priv->speed) {
- ctrl &= ~priv->hw->link.speed_mask;
-
- switch (phydev->speed) {
- case SPEED_1000:
- ctrl |= priv->hw->link.speed1000;
- break;
- case SPEED_100:
- ctrl |= priv->hw->link.speed100;
- break;
- case SPEED_10:
- ctrl |= priv->hw->link.speed10;
- break;
- default:
- netif_warn(priv, link, priv->dev,
- "broken speed: %d\n", phydev->speed);
- phydev->speed = SPEED_UNKNOWN;
- break;
- }
-
- if (phydev->speed != SPEED_UNKNOWN)
- stmmac_hw_fix_mac_speed(priv);
-
- priv->speed = phydev->speed;
+ switch (state->speed) {
+ case SPEED_1000:
+ ctrl |= priv->hw->link.speed1000;
+ break;
+ case SPEED_100:
+ ctrl |= priv->hw->link.speed100;
+ break;
+ case SPEED_10:
+ ctrl |= priv->hw->link.speed10;
+ break;
+ default:
+ return;
}

- /* Now we make sure that we can be in full duplex mode.
- * If not, we operate in half-duplex mode. */
- if (phydev->duplex != priv->oldduplex) {
- if (!phydev->duplex)
- ctrl &= ~priv->hw->link.duplex;
- else
- ctrl |= priv->hw->link.duplex;
+ priv->speed = state->speed;

- priv->oldduplex = phydev->duplex;
- }
+ if (priv->plat->fix_mac_speed)
+ priv->plat->fix_mac_speed(priv->plat->bsp_priv, state->speed);
+
+ if (!state->duplex)
+ ctrl &= ~priv->hw->link.duplex;
+ else
+ ctrl |= priv->hw->link.duplex;

/* Flow Control operation */
- if (phydev->pause)
- stmmac_mac_flow_ctrl(priv, phydev->duplex);
+ if (state->pause)
+ stmmac_mac_flow_ctrl(priv, state->duplex);

writel(ctrl, priv->ioaddr + MAC_CTRL_REG);
}
@@ -939,85 +885,40 @@ static void stmmac_mac_an_restart(struct phylink_config *config)
/* Not Supported */
}

-static void stmmac_mac_link_down(struct net_device *dev, bool autoneg)
+static void stmmac_mac_link_down(struct phylink_config *config,
+ unsigned int mode, phy_interface_t interface)
{
- struct stmmac_priv *priv = netdev_priv(dev);
+ struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));

stmmac_mac_set(priv, priv->ioaddr, false);
+ priv->eee_active = false;
+ stmmac_eee_init(priv);
+ stmmac_set_eee_pls(priv, priv->hw, false);
}

-static void stmmac_mac_link_up(struct net_device *dev, bool autoneg)
+static void stmmac_mac_link_up(struct phylink_config *config,
+ unsigned int mode, phy_interface_t interface,
+ struct phy_device *phy)
{
- struct stmmac_priv *priv = netdev_priv(dev);
+ struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));

stmmac_mac_set(priv, priv->ioaddr, true);
+ if (phy) {
+ priv->eee_active = phy_init_eee(phy, 1) >= 0;
+ priv->eee_enabled = stmmac_eee_init(priv);
+ stmmac_set_eee_pls(priv, priv->hw, true);
+ }
}

-static const struct phylink_mac_ops __maybe_unused stmmac_phylink_mac_ops = {
+static const struct phylink_mac_ops stmmac_phylink_mac_ops = {
.validate = stmmac_validate,
.mac_link_state = stmmac_mac_link_state,
- .mac_config = NULL, /* TO BE FILLED */
+ .mac_config = stmmac_mac_config,
.mac_an_restart = stmmac_mac_an_restart,
- .mac_link_down = NULL, /* TO BE FILLED */
- .mac_link_up = NULL, /* TO BE FILLED */
+ .mac_link_down = stmmac_mac_link_down,
+ .mac_link_up = stmmac_mac_link_up,
};

-/**
- * stmmac_adjust_link - adjusts the link parameters
- * @dev: net device structure
- * Description: this is the helper called by the physical abstraction layer
- * drivers to communicate the phy link status. According the speed and duplex
- * this driver can invoke registered glue-logic as well.
- * It also invoke the eee initialization because it could happen when switch
- * on different networks (that are eee capable).
- */
-static void stmmac_adjust_link(struct net_device *dev)
-{
- struct stmmac_priv *priv = netdev_priv(dev);
- struct phy_device *phydev = dev->phydev;
- bool new_state = false;
-
- if (!phydev)
- return;
-
- mutex_lock(&priv->lock);
-
- if (phydev->link) {
- stmmac_mac_config(dev);
-
- if (!priv->oldlink) {
- new_state = true;
- priv->oldlink = true;
- }
- } else if (priv->oldlink) {
- new_state = true;
- priv->oldlink = false;
- priv->speed = SPEED_UNKNOWN;
- priv->oldduplex = DUPLEX_UNKNOWN;
- }
-
- if (phydev->link)
- stmmac_mac_link_up(dev, false);
- else
- stmmac_mac_link_down(dev, false);
-
- if (new_state && netif_msg_link(priv))
- phy_print_status(phydev);
-
- mutex_unlock(&priv->lock);
-
- if (phydev->is_pseudo_fixed_link)
- /* Stop PHY layer to call the hook to adjust the link in case
- * of a switch is attached to the stmmac driver.
- */
- phydev->irq = PHY_IGNORE_INTERRUPT;
- else
- /* At this stage, init the EEE if supported.
- * Never called in case of fixed_link.
- */
- priv->eee_enabled = stmmac_eee_init(priv);
-}
-
/**
* stmmac_check_pcs_mode - verify if RGMII/SGMII is supported
* @priv: driver private structure
@@ -1054,79 +955,44 @@ static void stmmac_check_pcs_mode(struct stmmac_priv *priv)
static int stmmac_init_phy(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
- u32 tx_cnt = priv->plat->tx_queues_to_use;
- struct phy_device *phydev;
- char phy_id_fmt[MII_BUS_ID_SIZE + 3];
- char bus_id[MII_BUS_ID_SIZE];
- int interface = priv->plat->interface;
- int max_speed = priv->plat->max_speed;
- priv->oldlink = false;
- priv->speed = SPEED_UNKNOWN;
- priv->oldduplex = DUPLEX_UNKNOWN;
-
- if (priv->plat->phy_node) {
- phydev = of_phy_connect(dev, priv->plat->phy_node,
- &stmmac_adjust_link, 0, interface);
- } else {
- snprintf(bus_id, MII_BUS_ID_SIZE, "stmmac-%x",
- priv->plat->bus_id);
+ struct device_node *node;
+ int ret;

- snprintf(phy_id_fmt, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
- priv->plat->phy_addr);
- netdev_dbg(priv->dev, "%s: trying to attach to %s\n", __func__,
- phy_id_fmt);
+ node = priv->plat->phy_node;

- phydev = phy_connect(dev, phy_id_fmt, &stmmac_adjust_link,
- interface);
- }
+ if (node) {
+ ret = phylink_of_phy_connect(priv->phylink, node, 0);
+ } else {
+ int addr = priv->plat->phy_addr;
+ struct phy_device *phydev;

- if (IS_ERR_OR_NULL(phydev)) {
- netdev_err(priv->dev, "Could not attach to PHY\n");
- if (!phydev)
+ phydev = mdiobus_get_phy(priv->mii, addr);
+ if (!phydev) {
+ netdev_err(priv->dev, "no phy at addr %d\n", addr);
return -ENODEV;
+ }

- return PTR_ERR(phydev);
+ ret = phylink_connect_phy(priv->phylink, phydev);
}

- /* Stop Advertising 1000BASE Capability if interface is not GMII */
- if ((interface == PHY_INTERFACE_MODE_MII) ||
- (interface == PHY_INTERFACE_MODE_RMII) ||
- (max_speed < 1000 && max_speed > 0))
- phy_set_max_speed(phydev, SPEED_100);
+ return ret;
+}

- /*
- * Half-duplex mode not supported with multiqueue
- * half-duplex can only works with single queue
- */
- if (tx_cnt > 1) {
- phy_remove_link_mode(phydev,
- ETHTOOL_LINK_MODE_10baseT_Half_BIT);
- phy_remove_link_mode(phydev,
- ETHTOOL_LINK_MODE_100baseT_Half_BIT);
- phy_remove_link_mode(phydev,
- ETHTOOL_LINK_MODE_1000baseT_Half_BIT);
- }
+static int stmmac_phy_setup(struct stmmac_priv *priv)
+{
+ struct device_node *node = priv->plat->phy_node;
+ int mode = priv->plat->interface;
+ struct phylink *phylink;

- /*
- * Broken HW is sometimes missing the pull-up resistor on the
- * MDIO line, which results in reads to non-existent devices returning
- * 0 rather than 0xffff. Catch this here and treat 0 as a non-existent
- * device as well.
- * Note: phydev->phy_id is the result of reading the UID PHY registers.
- */
- if (!priv->plat->phy_node && phydev->phy_id == 0) {
- phy_disconnect(phydev);
- return -ENODEV;
- }
+ priv->phylink_config.dev = &priv->dev->dev;
+ priv->phylink_config.type = PHYLINK_NETDEV;

- /* stmmac_adjust_link will change this to PHY_IGNORE_INTERRUPT to avoid
- * subsequent PHY polling, make sure we force a link transition if
- * we have a UP/DOWN/UP transition
- */
- if (phydev->is_pseudo_fixed_link)
- phydev->irq = PHY_POLL;
+ phylink = phylink_create(&priv->phylink_config, of_fwnode_handle(node),
+ mode, &stmmac_phylink_mac_ops);
+ if (IS_ERR(phylink))
+ return PTR_ERR(phylink);

- phy_attached_info(phydev);
+ priv->phylink = phylink;
return 0;
}

@@ -2739,8 +2605,7 @@ static int stmmac_open(struct net_device *dev)

stmmac_init_tx_coalesce(priv);

- if (dev->phydev)
- phy_start(dev->phydev);
+ phylink_start(priv->phylink);

/* Request the IRQ lines */
ret = request_irq(dev->irq, stmmac_interrupt,
@@ -2787,8 +2652,7 @@ static int stmmac_open(struct net_device *dev)
wolirq_error:
free_irq(dev->irq, dev);
irq_error:
- if (dev->phydev)
- phy_stop(dev->phydev);
+ phylink_stop(priv->phylink);

for (chan = 0; chan < priv->plat->tx_queues_to_use; chan++)
del_timer_sync(&priv->tx_queue[chan].txtimer);
@@ -2797,9 +2661,7 @@ static int stmmac_open(struct net_device *dev)
init_error:
free_dma_desc_resources(priv);
dma_desc_error:
- if (dev->phydev)
- phy_disconnect(dev->phydev);
-
+ phylink_disconnect_phy(priv->phylink);
return ret;
}

@@ -2818,10 +2680,8 @@ static int stmmac_release(struct net_device *dev)
del_timer_sync(&priv->eee_ctrl_timer);

/* Stop and disconnect the PHY */
- if (dev->phydev) {
- phy_stop(dev->phydev);
- phy_disconnect(dev->phydev);
- }
+ phylink_stop(priv->phylink);
+ phylink_disconnect_phy(priv->phylink);

stmmac_stop_all_queues(priv);

@@ -3878,6 +3738,7 @@ static void stmmac_poll_controller(struct net_device *dev)
*/
static int stmmac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
+ struct stmmac_priv *priv = netdev_priv (dev);
int ret = -EOPNOTSUPP;

if (!netif_running(dev))
@@ -3887,9 +3748,7 @@ static int stmmac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
case SIOCGMIIPHY:
case SIOCGMIIREG:
case SIOCSMIIREG:
- if (!dev->phydev)
- return -EINVAL;
- ret = phy_mii_ioctl(dev->phydev, rq, cmd);
+ ret = phylink_mii_ioctl(priv->phylink, rq, cmd);
break;
case SIOCSHWTSTAMP:
ret = stmmac_hwtstamp_set(dev, rq);
@@ -4480,6 +4339,12 @@ int stmmac_dvr_probe(struct device *device,
}
}

+ ret = stmmac_phy_setup(priv);
+ if (ret) {
+ netdev_err(ndev, "failed to setup phy (%d)\n", ret);
+ goto error_phy_setup;
+ }
+
ret = register_netdev(ndev);
if (ret) {
dev_err(priv->device, "%s: ERROR %i registering the device\n",
@@ -4497,6 +4362,8 @@ int stmmac_dvr_probe(struct device *device,
return ret;

error_netdev_register:
+ phylink_destroy(priv->phylink);
+error_phy_setup:
if (priv->hw->pcs != STMMAC_PCS_RGMII &&
priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI)
@@ -4538,6 +4405,7 @@ int stmmac_dvr_remove(struct device *dev)
stmmac_mac_set(priv, priv->ioaddr, false);
netif_carrier_off(ndev);
unregister_netdev(ndev);
+ phylink_destroy(priv->phylink);
if (priv->plat->stmmac_rst)
reset_control_assert(priv->plat->stmmac_rst);
clk_disable_unprepare(priv->plat->pclk);
@@ -4568,8 +4436,7 @@ int stmmac_suspend(struct device *dev)
if (!ndev || !netif_running(ndev))
return 0;

- if (ndev->phydev)
- phy_stop(ndev->phydev);
+ phylink_stop(priv->phylink);

mutex_lock(&priv->lock);

@@ -4594,9 +4461,7 @@ int stmmac_suspend(struct device *dev)
}
mutex_unlock(&priv->lock);

- priv->oldlink = false;
priv->speed = SPEED_UNKNOWN;
- priv->oldduplex = DUPLEX_UNKNOWN;
return 0;
}
EXPORT_SYMBOL_GPL(stmmac_suspend);
@@ -4680,8 +4545,7 @@ int stmmac_resume(struct device *dev)

mutex_unlock(&priv->lock);

- if (ndev->phydev)
- phy_start(ndev->phydev);
+ phylink_start(priv->phylink);

return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index f45bfbef97d0..898f94aced53 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -333,21 +333,6 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
{},
};

- /* If phy-handle property is passed from DT, use it as the PHY */
- plat->phy_node = of_parse_phandle(np, "phy-handle", 0);
- if (plat->phy_node)
- dev_dbg(dev, "Found phy-handle subnode\n");
-
- /* If phy-handle is not specified, check if we have a fixed-phy */
- if (!plat->phy_node && of_phy_is_fixed_link(np)) {
- if ((of_phy_register_fixed_link(np) < 0))
- return -ENODEV;
-
- dev_dbg(dev, "Found fixed-link subnode\n");
- plat->phy_node = of_node_get(np);
- mdio = false;
- }
-
if (of_match_node(need_mdio_ids, np)) {
plat->mdio_node = of_get_child_by_name(np, "mdio");
} else {
@@ -396,6 +381,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)

*mac = of_get_mac_address(np);
plat->interface = of_get_phy_mode(np);
+ plat->phy_node = np;

/* Get max speed of operation from device tree */
if (of_property_read_u32(np, "max-speed", &plat->max_speed))
@@ -591,11 +577,6 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
void stmmac_remove_config_dt(struct platform_device *pdev,
struct plat_stmmacenet_data *plat)
{
- struct device_node *np = pdev->dev.of_node;
-
- if (of_phy_is_fixed_link(np))
- of_phy_deregister_fixed_link(np);
- of_node_put(plat->phy_node);
of_node_put(plat->mdio_node);
}
#else
--
2.21.0

2019-06-13 21:04:09

by David Miller

[permalink] [raw]
Subject: Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink

From: Jose Abreu <[email protected]>
Date: Tue, 11 Jun 2019 17:18:44 +0200

> [ Hope this diff looks better (generated with --minimal) ]
>
> This converts stmmac to use phylink. Besides the code redution this will
> allow to gain more flexibility.

Series applied, thank you.

2019-06-14 13:41:27

by Corentin Labbe

[permalink] [raw]
Subject: Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink

On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> [ Hope this diff looks better (generated with --minimal) ]
>
> This converts stmmac to use phylink. Besides the code redution this will
> allow to gain more flexibility.
>
> Cc: Joao Pinto <[email protected]>
> Cc: David S. Miller <[email protected]>
> Cc: Giuseppe Cavallaro <[email protected]>
> Cc: Alexandre Torgue <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: Andrew Lunn <[email protected]>
> Cc: Florian Fainelli <[email protected]>
> Cc: Heiner Kallweit <[email protected]>
>
> Jose Abreu (3):
> net: stmmac: Prepare to convert to phylink
> net: stmmac: Start adding phylink support
> net: stmmac: Convert to phylink and remove phylib logic
>
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 3 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +-
> .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +---
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 391 ++++++++----------
> .../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +-
> 5 files changed, 190 insertions(+), 313 deletions(-)
>
> --
> 2.21.0
>

Hello

since this patch I hit
dwmac-sun8i 1c30000.ethernet: ethernet@1c30000 PHY address 29556736 is too large

any idea ?

2019-06-14 14:48:07

by Jose Abreu

[permalink] [raw]
Subject: RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink

From: Corentin Labbe <[email protected]>

> since this patch I hit
> dwmac-sun8i 1c30000.ethernet: ethernet@1c30000 PHY address 29556736 is too large
>
> any idea ?

This is because phy_node is no longer pointing to the same place so
sun8i_dwmac_set_syscon() fails.

I'm seeing this pattern of using phy_node in other wrappers so I will
try to submit a fix for them all.

Thanks for reporting.

2019-06-18 09:30:59

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic


On 11/06/2019 16:18, Jose Abreu wrote:
> Convert everything to phylink.
>
> Signed-off-by: Jose Abreu <[email protected]>
> Cc: Joao Pinto <[email protected]>
> Cc: David S. Miller <[email protected]>
> Cc: Giuseppe Cavallaro <[email protected]>
> Cc: Alexandre Torgue <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: Andrew Lunn <[email protected]>
> Cc: Florian Fainelli <[email protected]>
> Cc: Heiner Kallweit <[email protected]>

I am seeing a boot regression on -next for some of our boards that have
a synopsys ethernet controller that uses the dwmac-dwc-qos-ethernet
driver. Git bisect is pointing to this commit, but unfortunately this
cannot be cleanly reverted on top of -next to confirm.

The bootlog shows the following bug is triggered ...

[ 10.784989] ------------[ cut here ]------------
[ 10.789597] kernel BUG at /home/jonathanh/workdir/tegra/mlt-linux_next/kernel/kernel/time/timer.c:952!
[ 10.798881] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 10.804351] Modules linked in:
[ 10.807400] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S 5.2.0-rc3-00940-g425b0fad9c7e #9
[ 10.816682] Hardware name: NVIDIA Tegra186 P2771-0000 Development Board (DT)
[ 10.823712] pstate: 20000005 (nzCv daif -PAN -UAO)
[ 10.828496] pc : mod_timer+0x208/0x2d8
[ 10.832235] lr : stmmac_napi_poll_tx+0x524/0x5a0
[ 10.836839] sp : ffff000010003d00
[ 10.840141] x29: ffff000010003d00 x28: ffff8001f42887c0
[ 10.845438] x27: ffff8001f42887c0 x26: ffff8001f55b7100
[ 10.850735] x25: 0000000000000000 x24: 0000000000000000
[ 10.856033] x23: ffff0000112e9000 x22: 0000000000000000
[ 10.861330] x21: 0000000000000001 x20: ffff0000121ad000
[ 10.866626] x19: ffff8001f47da000 x18: 0000000000000000
[ 10.871922] x17: 0000000000000000 x16: 0000000000000001
[ 10.877218] x15: 0000000000000009 x14: 0000000000001000
[ 10.882515] x13: 0000000080000000 x12: 0000000000000001
[ 10.887811] x11: 000000000000000c x10: 0000000000000000
[ 10.893107] x9 : 0000000000000000 x8 : 00000000fffee49c
[ 10.898403] x7 : 000000000000002a x6 : 000000000000002a
[ 10.903699] x5 : ffff8001f4189c80 x4 : 0000000000290000
[ 10.908995] x3 : 0000000000000000 x2 : 0000000000000000
[ 10.914291] x1 : 00000000fffee596 x0 : ffff8001f428b160
[ 10.919587] Call trace:
[ 10.922024] mod_timer+0x208/0x2d8
[ 10.925415] stmmac_napi_poll_tx+0x524/0x5a0
[ 10.929674] net_rx_action+0x220/0x318
[ 10.933413] __do_softirq+0x110/0x23c
[ 10.937066] irq_exit+0xcc/0xd8
[ 10.940199] __handle_domain_irq+0x60/0xb8
[ 10.944282] gic_handle_irq+0x58/0xb0
[ 10.947931] el1_irq+0xb8/0x180
[ 10.951063] arch_cpu_idle+0x10/0x18
[ 10.954627] do_idle+0x1dc/0x2a8
[ 10.957845] cpu_startup_entry+0x24/0x28
[ 10.961758] rest_init+0xd4/0xe0
[ 10.964978] arch_call_rest_init+0xc/0x14
[ 10.968976] start_kernel+0x44c/0x478
[ 10.972626] Code: aa1503f4 aa1403f5 17ffffc5 d503201f (d4210000)
[ 10.978709] ---[ end trace 89626c50aaab321f ]---

I have not looked at this any further, but wanted to see if you have some
thoughts.

Cheers
Jon

--
nvpublic

2019-06-18 09:36:31

by Jose Abreu

[permalink] [raw]
Subject: RE: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic

From: Jon Hunter <[email protected]>

> I am seeing a boot regression on -next for some of our boards that have
> a synopsys ethernet controller that uses the dwmac-dwc-qos-ethernet
> driver. Git bisect is pointing to this commit, but unfortunately this
> cannot be cleanly reverted on top of -next to confirm.

Thanks for reporting. Looks like the timer is not setup when
stmmac_tx_clean() is called. When do you see this stacktrace ? After
ifdown ?

Thanks,
Jose Miguel Abreu

2019-06-18 09:44:15

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic


On 18/06/2019 10:35, Jose Abreu wrote:
> From: Jon Hunter <[email protected]>
>
>> I am seeing a boot regression on -next for some of our boards that have
>> a synopsys ethernet controller that uses the dwmac-dwc-qos-ethernet
>> driver. Git bisect is pointing to this commit, but unfortunately this
>> cannot be cleanly reverted on top of -next to confirm.
>
> Thanks for reporting. Looks like the timer is not setup when
> stmmac_tx_clean() is called. When do you see this stacktrace ? After
> ifdown ?

I am not certain but I don't believe so. We are using a static IP address
and mounting the root file-system via NFS when we see this ...

[ 10.607510] dwc-eth-dwmac 2490000.ethernet eth0: phy link up rgmii/1Gbps/Full
[ 10.607536] dwc-eth-dwmac 2490000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
[ 10.608804] dwc-eth-dwmac 2490000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 10.630979] IP-Config: Complete:
[ 10.639046] device=eth0, hwaddr=d2:e5:1c:57:26:4b, ipaddr=192.168.99.2, mask=255.255.255.0, gw=192.168.99.1
[ 10.649201] host=192.168.99.2, domain=, nis-domain=(none)
[ 10.655022] bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=
[ 10.677531] VDD_1V8_AP_PLL: disabling
[ 10.681194] VDD_RTC: disabling
[ 10.684246] VDDIO_SDMMC3_AP: disabling
[ 10.688132] VDD_HDMI_1V05: disabling
[ 10.691704] SD_CARD_SW_PWR: disabling
[ 10.695357] VDD_USB0: disabling
[ 10.698488] VDD_USB1: disabling
[ 10.701621] VDD_HDMI_5V0: disabling
[ 10.705100] ALSA device list:
[ 10.708063] No soundcards found.
[ 10.711914] Freeing unused kernel memory: 1472K
[ 10.727005] Run /init as init process
[ 10.784989] ------------[ cut here ]------------
[ 10.789597] kernel BUG at /home/jonathanh/workdir/tegra/mlt-linux_next/kernel/kernel/time/timer.c:952!

Cheers
Jon

--
nvpublic

2019-06-18 09:47:53

by Jose Abreu

[permalink] [raw]
Subject: RE: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic

From: Jon Hunter <[email protected]>

> I am not certain but I don't believe so. We are using a static IP address
> and mounting the root file-system via NFS when we see this ...

Can you please add a call to napi_synchronize() before every
napi_disable() calls, like this:

if (queue < rx_queues_cnt) {
napi_synchronize(&ch->rx_napi);
napi_disable(&ch->rx_napi);
}

if (queue < tx_queues_cnt) {
napi_synchronize(&ch->tx_napi);
napi_disable(&ch->tx_napi);
}

[ I can send you a patch if you prefer ]

Thanks,
Jose Miguel Abreu

2019-06-18 10:19:26

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic


On 18/06/2019 10:46, Jose Abreu wrote:
> From: Jon Hunter <[email protected]>
>
>> I am not certain but I don't believe so. We are using a static IP address
>> and mounting the root file-system via NFS when we see this ...
>
> Can you please add a call to napi_synchronize() before every
> napi_disable() calls, like this:
>
> if (queue < rx_queues_cnt) {
> napi_synchronize(&ch->rx_napi);
> napi_disable(&ch->rx_napi);
> }
>
> if (queue < tx_queues_cnt) {
> napi_synchronize(&ch->tx_napi);
> napi_disable(&ch->tx_napi);
> }
>
> [ I can send you a patch if you prefer ]

Yes I can try this and for completeness you mean ...

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4ca46289a742..d4a12cb64d8e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -146,10 +146,15 @@ static void stmmac_disable_all_queues(struct stmmac_priv *priv)
for (queue = 0; queue < maxq; queue++) {
struct stmmac_channel *ch = &priv->channel[queue];

- if (queue < rx_queues_cnt)
+ if (queue < rx_queues_cnt) {
+ napi_synchronize(&ch->rx_napi);
napi_disable(&ch->rx_napi);
- if (queue < tx_queues_cnt)
+ }
+
+ if (queue < tx_queues_cnt) {
+ napi_synchronize(&ch->tx_napi);
napi_disable(&ch->tx_napi);
+ }
}
}

Cheers
Jon

--
nvpublic

2019-06-18 15:21:06

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic


On 18/06/2019 11:18, Jon Hunter wrote:
>
> On 18/06/2019 10:46, Jose Abreu wrote:
>> From: Jon Hunter <[email protected]>
>>
>>> I am not certain but I don't believe so. We are using a static IP address
>>> and mounting the root file-system via NFS when we see this ...
>>
>> Can you please add a call to napi_synchronize() before every
>> napi_disable() calls, like this:
>>
>> if (queue < rx_queues_cnt) {
>> napi_synchronize(&ch->rx_napi);
>> napi_disable(&ch->rx_napi);
>> }
>>
>> if (queue < tx_queues_cnt) {
>> napi_synchronize(&ch->tx_napi);
>> napi_disable(&ch->tx_napi);
>> }
>>
>> [ I can send you a patch if you prefer ]
>
> Yes I can try this and for completeness you mean ...
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 4ca46289a742..d4a12cb64d8e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -146,10 +146,15 @@ static void stmmac_disable_all_queues(struct stmmac_priv *priv)
> for (queue = 0; queue < maxq; queue++) {
> struct stmmac_channel *ch = &priv->channel[queue];
>
> - if (queue < rx_queues_cnt)
> + if (queue < rx_queues_cnt) {
> + napi_synchronize(&ch->rx_napi);
> napi_disable(&ch->rx_napi);
> - if (queue < tx_queues_cnt)
> + }
> +
> + if (queue < tx_queues_cnt) {
> + napi_synchronize(&ch->tx_napi);
> napi_disable(&ch->tx_napi);
> + }
> }
> }

So good news and bad news ...

The good news is that the above change does fix the initial crash
I am seeing. However, even with this change applied on top of
-next, it is still dying somewhere else and so there appears to
be a second issue.

On a successful boot I see ...

[ 6.150419] dwc-eth-dwmac 2490000.ethernet: Cannot get CSR clock

[ 6.156441] dwc-eth-dwmac 2490000.ethernet: no reset control found

[ 6.175866] dwc-eth-dwmac 2490000.ethernet: User ID: 0x10, Synopsys ID: 0x41

[ 6.182912] dwc-eth-dwmac 2490000.ethernet: DWMAC4/5

[ 6.187961] dwc-eth-dwmac 2490000.ethernet: DMA HW capability register supported

[ 6.195351] dwc-eth-dwmac 2490000.ethernet: RX Checksum Offload Engine supported

[ 6.202735] dwc-eth-dwmac 2490000.ethernet: TX Checksum insertion supported

[ 6.209685] dwc-eth-dwmac 2490000.ethernet: Wake-Up On Lan supported

[ 6.216041] dwc-eth-dwmac 2490000.ethernet: TSO supported

[ 6.221433] dwc-eth-dwmac 2490000.ethernet: Enable RX Mitigation via HW Watchdog Timer

[ 6.229342] dwc-eth-dwmac 2490000.ethernet: device MAC address 9a:9b:49:6f:a5:ee

[ 6.236727] dwc-eth-dwmac 2490000.ethernet: TSO feature enabled

[ 6.242689] libphy: stmmac: probed

On the latest -next with the patch applied I see ...

[ 6.043529] dwc-eth-dwmac 2490000.ethernet: Cannot get CSR clock
[ 6.049546] dwc-eth-dwmac 2490000.ethernet: no reset control found
[ 6.068895] dwc-eth-dwmac 2490000.ethernet: User ID: 0x10, Synopsys ID: 0x41
[ 6.075941] dwc-eth-dwmac 2490000.ethernet: DWMAC4/5
[ 6.080989] dwc-eth-dwmac 2490000.ethernet: DMA HW capability register supported
[ 6.088373] dwc-eth-dwmac 2490000.ethernet: RX Checksum Offload Engine supported
[ 6.095756] dwc-eth-dwmac 2490000.ethernet: TX Checksum insertion supported
[ 6.102708] dwc-eth-dwmac 2490000.ethernet: Wake-Up On Lan supported
[ 6.109074] dwc-eth-dwmac 2490000.ethernet: TSO supported
[ 6.114465] dwc-eth-dwmac 2490000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[ 6.122373] dwc-eth-dwmac 2490000.ethernet: device MAC address ee:3a:9a:b0:7e:34
[ 6.129756] dwc-eth-dwmac 2490000.ethernet: TSO feature enabled

And it dies here. No more output is seen. I will try to figure
out which commit is causing this issue.

Cheers
Jon

--
nvpublic

2019-06-18 19:45:11

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic


On 18/06/2019 16:20, Jon Hunter wrote:
>
> On 18/06/2019 11:18, Jon Hunter wrote:
>>
>> On 18/06/2019 10:46, Jose Abreu wrote:
>>> From: Jon Hunter <[email protected]>
>>>
>>>> I am not certain but I don't believe so. We are using a static IP address
>>>> and mounting the root file-system via NFS when we see this ...
>>>
>>> Can you please add a call to napi_synchronize() before every
>>> napi_disable() calls, like this:
>>>
>>> if (queue < rx_queues_cnt) {
>>> napi_synchronize(&ch->rx_napi);
>>> napi_disable(&ch->rx_napi);
>>> }
>>>
>>> if (queue < tx_queues_cnt) {
>>> napi_synchronize(&ch->tx_napi);
>>> napi_disable(&ch->tx_napi);
>>> }
>>>
>>> [ I can send you a patch if you prefer ]
>>
>> Yes I can try this and for completeness you mean ...
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 4ca46289a742..d4a12cb64d8e 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -146,10 +146,15 @@ static void stmmac_disable_all_queues(struct stmmac_priv *priv)
>> for (queue = 0; queue < maxq; queue++) {
>> struct stmmac_channel *ch = &priv->channel[queue];
>>
>> - if (queue < rx_queues_cnt)
>> + if (queue < rx_queues_cnt) {
>> + napi_synchronize(&ch->rx_napi);
>> napi_disable(&ch->rx_napi);
>> - if (queue < tx_queues_cnt)
>> + }
>> +
>> + if (queue < tx_queues_cnt) {
>> + napi_synchronize(&ch->tx_napi);
>> napi_disable(&ch->tx_napi);
>> + }
>> }
>> }
>
> So good news and bad news ...
>
> The good news is that the above change does fix the initial crash
> I am seeing. However, even with this change applied on top of
> -next, it is still dying somewhere else and so there appears to
> be a second issue.

Further testing has shown that actually this does NOT resolve the issue
and I am still seeing the crash. Sorry for the false-positive.

Jon

--
nvpublic

2019-06-20 14:05:53

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic


On 18/06/2019 20:44, Jon Hunter wrote:
>
> On 18/06/2019 16:20, Jon Hunter wrote:
>>
>> On 18/06/2019 11:18, Jon Hunter wrote:
>>>
>>> On 18/06/2019 10:46, Jose Abreu wrote:
>>>> From: Jon Hunter <[email protected]>
>>>>
>>>>> I am not certain but I don't believe so. We are using a static IP address
>>>>> and mounting the root file-system via NFS when we see this ...
>>>>
>>>> Can you please add a call to napi_synchronize() before every
>>>> napi_disable() calls, like this:
>>>>
>>>> if (queue < rx_queues_cnt) {
>>>> napi_synchronize(&ch->rx_napi);
>>>> napi_disable(&ch->rx_napi);
>>>> }
>>>>
>>>> if (queue < tx_queues_cnt) {
>>>> napi_synchronize(&ch->tx_napi);
>>>> napi_disable(&ch->tx_napi);
>>>> }
>>>>
>>>> [ I can send you a patch if you prefer ]
>>>
>>> Yes I can try this and for completeness you mean ...
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> index 4ca46289a742..d4a12cb64d8e 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> @@ -146,10 +146,15 @@ static void stmmac_disable_all_queues(struct stmmac_priv *priv)
>>> for (queue = 0; queue < maxq; queue++) {
>>> struct stmmac_channel *ch = &priv->channel[queue];
>>>
>>> - if (queue < rx_queues_cnt)
>>> + if (queue < rx_queues_cnt) {
>>> + napi_synchronize(&ch->rx_napi);
>>> napi_disable(&ch->rx_napi);
>>> - if (queue < tx_queues_cnt)
>>> + }
>>> +
>>> + if (queue < tx_queues_cnt) {
>>> + napi_synchronize(&ch->tx_napi);
>>> napi_disable(&ch->tx_napi);
>>> + }
>>> }
>>> }
>>
>> So good news and bad news ...
>>
>> The good news is that the above change does fix the initial crash
>> I am seeing. However, even with this change applied on top of
>> -next, it is still dying somewhere else and so there appears to
>> be a second issue.
>
> Further testing has shown that actually this does NOT resolve the issue
> and I am still seeing the crash. Sorry for the false-positive.

Any further feedback? I am still seeing this issue on today's -next.

Thanks
Jon

--
nvpublic

2019-06-25 07:54:27

by Jose Abreu

[permalink] [raw]
Subject: RE: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic

From: Jon Hunter <[email protected]>

> Any further feedback? I am still seeing this issue on today's -next.

Apologies but I was in FTO.

Is there any possibility you can just disable the ethX configuration in
the rootfs mount and manually configure it after rootfs is done ?

I just want to make sure in which conditions this is happening (if in
ifdown or ifup).

Thanks,
Jose Miguel Abreu

2019-06-25 12:58:11

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic


On 25/06/2019 08:37, Jose Abreu wrote:
> From: Jon Hunter <[email protected]>
>
>> Any further feedback? I am still seeing this issue on today's -next.
>
> Apologies but I was in FTO.
>
> Is there any possibility you can just disable the ethX configuration in
> the rootfs mount and manually configure it after rootfs is done ?
>
> I just want to make sure in which conditions this is happening (if in
> ifdown or ifup).

I have been looking at this a bit closer and I can see the problem. What
happens is that ...

1. stmmac_mac_link_up() is called and priv->eee_active is set to false
2. stmmac_eee_init() is called but because priv->eee_active is false,
timer_setup() for eee_ctrl_timer is never called.
3. stmmac_eee_init() returns true and so then priv->eee_enabled is set
to true.
4. When stmmac_tx_clean() is called because priv->eee_enabled is set to
true, mod_timer() is called for the eee_ctrl_timer, but because
timer_setup() was never called, we hit the BUG defined at
kernel/time/timer.c:952, because no function is defined for the
timer.

The following fixes it for me ...

--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -399,10 +399,13 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
mutex_lock(&priv->lock);

/* Check if it needs to be deactivated */
- if (!priv->eee_active && priv->eee_enabled) {
- netdev_dbg(priv->dev, "disable EEE\n");
- del_timer_sync(&priv->eee_ctrl_timer);
- stmmac_set_eee_timer(priv, priv->hw, 0, tx_lpi_timer);
+ if (!priv->eee_active) {
+ if (priv->eee_enabled) {
+ netdev_dbg(priv->dev, "disable EEE\n");
+ del_timer_sync(&priv->eee_ctrl_timer);
+ stmmac_set_eee_timer(priv, priv->hw, 0, tx_lpi_timer);
+ }
+ mutex_unlock(&priv->lock);
return false;
}

It also looks like you have a potention deadlock in the current code
because in the case of if (!priv->eee_active && priv->eee_enabled)
you don't unlock the mutex. The above fixes this as well. I can send a
formal patch if this looks correct.

Cheers
Jon

--
nvpublic

2019-06-25 13:04:51

by Jose Abreu

[permalink] [raw]
Subject: RE: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic

From: Jon Hunter <[email protected]>

> I have been looking at this a bit closer and I can see the problem. What
> happens is that ...
>
> 1. stmmac_mac_link_up() is called and priv->eee_active is set to false
> 2. stmmac_eee_init() is called but because priv->eee_active is false,
> timer_setup() for eee_ctrl_timer is never called.
> 3. stmmac_eee_init() returns true and so then priv->eee_enabled is set
> to true.
> 4. When stmmac_tx_clean() is called because priv->eee_enabled is set to
> true, mod_timer() is called for the eee_ctrl_timer, but because
> timer_setup() was never called, we hit the BUG defined at
> kernel/time/timer.c:952, because no function is defined for the
> timer.
>
> The following fixes it for me ...
>
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -399,10 +399,13 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
> mutex_lock(&priv->lock);
>
> /* Check if it needs to be deactivated */
> - if (!priv->eee_active && priv->eee_enabled) {
> - netdev_dbg(priv->dev, "disable EEE\n");
> - del_timer_sync(&priv->eee_ctrl_timer);
> - stmmac_set_eee_timer(priv, priv->hw, 0, tx_lpi_timer);
> + if (!priv->eee_active) {
> + if (priv->eee_enabled) {
> + netdev_dbg(priv->dev, "disable EEE\n");
> + del_timer_sync(&priv->eee_ctrl_timer);
> + stmmac_set_eee_timer(priv, priv->hw, 0, tx_lpi_timer);
> + }
> + mutex_unlock(&priv->lock);
> return false;
> }
>
> It also looks like you have a potention deadlock in the current code
> because in the case of if (!priv->eee_active && priv->eee_enabled)
> you don't unlock the mutex. The above fixes this as well. I can send a
> formal patch if this looks correct.

Thanks for looking into this! The fix looks correct so if you could
submit a patch it would be great!

Thanks,
Jose Miguel Abreu

2019-07-22 13:11:17

by Ondřej Jirman

[permalink] [raw]
Subject: Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink

Hello Jose,

On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> [ Hope this diff looks better (generated with --minimal) ]
>
> This converts stmmac to use phylink. Besides the code redution this will
> allow to gain more flexibility.

I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to
5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed.

After going through stmmac patches since 5.2, I think it may be realted to this
series, but I'm not completely sure. You'll probably have a better understanding
of the changes. Do you have an idea what might be wrong? Please, see some logs
below.

thank you and regards,
Ondrej

On 5.3-rc1 I see:

[ 6.116512] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
[ 6.116522] dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062cf advertising 00,00000000,000062cf
[ 6.118714] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
[ 6.118725] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
[ 6.118730] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
[ 6.118738] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
[ 6.118747] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062cf pause=10 link=0 an=1
[ 6.126099] dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
[ 6.276325] random: crng init done
[ 6.276338] random: 7 urandom warning(s) missed due to ratelimiting
[ 7.543987] zram0: detected capacity change from 0 to 402653184
[ 7.667702] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 across:393212k SS

... delay due to other causes ...

[ 28.640234] dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/10Mbps/Full
[ 28.640295] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/10Mbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
[ 28.640324] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 10Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes

On 5.2 it looks like this:

[ 1.153596] dwmac-sun8i 5020000.ethernet: PTP uses main clock
[ 1.416221] dwmac-sun8i 5020000.ethernet: PTP uses main clock
[ 1.522735] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
[ 1.522750] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
[ 1.522753] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
[ 1.522755] dwmac-sun8i 5020000.ethernet: COE Type 2
[ 1.522758] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
[ 1.522761] dwmac-sun8i 5020000.ethernet: Normal descriptors
[ 1.522763] dwmac-sun8i 5020000.ethernet: Chain mode enabled
[ 5.352833] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
[ 5.352842] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
[ 5.352846] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
[ 10.463072] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes


> Cc: Joao Pinto <[email protected]>
> Cc: David S. Miller <[email protected]>
> Cc: Giuseppe Cavallaro <[email protected]>
> Cc: Alexandre Torgue <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: Andrew Lunn <[email protected]>
> Cc: Florian Fainelli <[email protected]>
> Cc: Heiner Kallweit <[email protected]>
>
> Jose Abreu (3):
> net: stmmac: Prepare to convert to phylink
> net: stmmac: Start adding phylink support
> net: stmmac: Convert to phylink and remove phylib logic
>
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 3 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +-
> .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +---
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 391 ++++++++----------
> .../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +-
> 5 files changed, 190 insertions(+), 313 deletions(-)
>
> --
> 2.21.0
>


Attachments:
(No filename) (6.18 kB)
signature.asc (235.00 B)
Download all attachments

2019-07-22 13:41:20

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink

On Mon, Jul 22, 2019 at 01:28:51PM +0000, Jose Abreu wrote:
> From: Ondřej Jirman <[email protected]>
> Date: Jul/22/2019, 13:42:40 (UTC+00:00)
>
> > Hello Jose,
> >
> > On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> > > [ Hope this diff looks better (generated with --minimal) ]
> > >
> > > This converts stmmac to use phylink. Besides the code redution this will
> > > allow to gain more flexibility.
> >
> > I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to
> > 5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed.
> >
> > After going through stmmac patches since 5.2, I think it may be realted to this
> > series, but I'm not completely sure. You'll probably have a better understanding
> > of the changes. Do you have an idea what might be wrong? Please, see some logs
> > below.
>
> Probably due to:
> 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
>
> Can you try attached patch ?
>

Hi Jose

Does this mean that all stmmac variants support 1G? There are none
which just support Fast Ethernet?

I'm also not sure the change fits the problem. Why did it not
negotiate 100FULL rather than 10Half? You are only moving the 1G
speeds around, so 100 speeds should of been advertised and selected.

Thanks
Andrew

2019-07-22 13:59:01

by Jose Abreu

[permalink] [raw]
Subject: RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink

From: Andrew Lunn <[email protected]>
Date: Jul/22/2019, 14:40:23 (UTC+00:00)

> Does this mean that all stmmac variants support 1G? There are none
> which just support Fast Ethernet?

This glue logic drivers sometimes reflect a custom IP that's Synopsys
based but modified by customer, so I can't know before-hand what's the
supported max speed. There are some old versions that don't support 1G
but I expect that PHY driver limits this ...

> I'm also not sure the change fits the problem. Why did it not
> negotiate 100FULL rather than 10Half? You are only moving the 1G
> speeds around, so 100 speeds should of been advertised and selected.

Hmm, now that I'm looking at it closer I agree with you. Maybe link
partner or PHY doesn't support 100M ?

It's working for Ondrej but I got curious now ...

---
Thanks,
Jose Miguel Abreu

2019-07-22 15:46:51

by Jose Abreu

[permalink] [raw]
Subject: RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink

From: Ond?ej Jirman <[email protected]>
Date: Jul/22/2019, 13:42:40 (UTC+00:00)

> Hello Jose,
>
> On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> > [ Hope this diff looks better (generated with --minimal) ]
> >
> > This converts stmmac to use phylink. Besides the code redution this will
> > allow to gain more flexibility.
>
> I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to
> 5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed.
>
> After going through stmmac patches since 5.2, I think it may be realted to this
> series, but I'm not completely sure. You'll probably have a better understanding
> of the changes. Do you have an idea what might be wrong? Please, see some logs
> below.

Probably due to:
5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")

Can you try attached patch ?


>
> thank you and regards,
> Ondrej
>
> On 5.3-rc1 I see:
>
> [ 6.116512] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
> [ 6.116522] dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062cf advertising 00,00000000,000062cf
> [ 6.118714] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> [ 6.118725] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> [ 6.118730] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> [ 6.118738] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
> [ 6.118747] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062cf pause=10 link=0 an=1
> [ 6.126099] dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
> [ 6.276325] random: crng init done
> [ 6.276338] random: 7 urandom warning(s) missed due to ratelimiting
> [ 7.543987] zram0: detected capacity change from 0 to 402653184
> [ 7.667702] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 across:393212k SS
>
> ... delay due to other causes ...
>
> [ 28.640234] dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/10Mbps/Full
> [ 28.640295] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/10Mbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
> [ 28.640324] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx
>
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Advertised pause frame use: Symmetric Receive-only
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> Link partner advertised pause frame use: Symmetric Receive-only
> Link partner advertised auto-negotiation: Yes
> Link partner advertised FEC modes: Not reported
> Speed: 10Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: d
> Wake-on: d
> Current message level: 0x0000003f (63)
> drv probe link timer ifdown ifup
> Link detected: yes
>
> On 5.2 it looks like this:
>
> [ 1.153596] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> [ 1.416221] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> [ 1.522735] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
> [ 1.522750] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
> [ 1.522753] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
> [ 1.522755] dwmac-sun8i 5020000.ethernet: COE Type 2
> [ 1.522758] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
> [ 1.522761] dwmac-sun8i 5020000.ethernet: Normal descriptors
> [ 1.522763] dwmac-sun8i 5020000.ethernet: Chain mode enabled
> [ 5.352833] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> [ 5.352842] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> [ 5.352846] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> [ 10.463072] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Link partner advertised pause frame use: Symmetric Receive-only
> Link partner advertised auto-negotiation: Yes
> Link partner advertised FEC modes: Not reported
> Speed: 1000Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: d
> Wake-on: d
> Current message level: 0x0000003f (63)
> drv probe link timer ifdown ifup
> Link detected: yes
>
>
> > Cc: Joao Pinto <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Cc: Giuseppe Cavallaro <[email protected]>
> > Cc: Alexandre Torgue <[email protected]>
> > Cc: Russell King <[email protected]>
> > Cc: Andrew Lunn <[email protected]>
> > Cc: Florian Fainelli <[email protected]>
> > Cc: Heiner Kallweit <[email protected]>
> >
> > Jose Abreu (3):
> > net: stmmac: Prepare to convert to phylink
> > net: stmmac: Start adding phylink support
> > net: stmmac: Convert to phylink and remove phylib logic
> >
> > drivers/net/ethernet/stmicro/stmmac/Kconfig | 3 +-
> > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +-
> > .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +---
> > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 391 ++++++++----------
> > .../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +-
> > 5 files changed, 190 insertions(+), 313 deletions(-)
> >
> > --
> > 2.21.0
> >


---
Thanks,
Jose Miguel Abreu


Attachments:
0001-net-stmmac-Do-not-cut-down-1G-modes.patch (2.26 kB)
0001-net-stmmac-Do-not-cut-down-1G-modes.patch

2019-07-22 16:43:47

by Ondřej Jirman

[permalink] [raw]
Subject: Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink

On Mon, Jul 22, 2019 at 01:28:51PM +0000, Jose Abreu wrote:
> From: Ondřej Jirman <[email protected]>
> Date: Jul/22/2019, 13:42:40 (UTC+00:00)
>
> > Hello Jose,
> >
> > On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> > > [ Hope this diff looks better (generated with --minimal) ]
> > >
> > > This converts stmmac to use phylink. Besides the code redution this will
> > > allow to gain more flexibility.
> >
> > I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to
> > 5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed.
> >
> > After going through stmmac patches since 5.2, I think it may be realted to this
> > series, but I'm not completely sure. You'll probably have a better understanding
> > of the changes. Do you have an idea what might be wrong? Please, see some logs
> > below.
>
> Probably due to:
> 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
>
> Can you try attached patch ?

Tried, and it works!

dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062ff advertising 00,00000000,000062ff
dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062ff pause=10 link=0 an=1
dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/1Gbps/Full
dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Tested-by: Ondrej Jirman <[email protected]>

thank you,
Ondrej

>
> >
> > thank you and regards,
> > Ondrej
> >
> > On 5.3-rc1 I see:
> >
> > [ 6.116512] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
> > [ 6.116522] dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062cf advertising 00,00000000,000062cf
> > [ 6.118714] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> > [ 6.118725] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> > [ 6.118730] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> > [ 6.118738] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
> > [ 6.118747] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062cf pause=10 link=0 an=1
> > [ 6.126099] dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
> > [ 6.276325] random: crng init done
> > [ 6.276338] random: 7 urandom warning(s) missed due to ratelimiting
> > [ 7.543987] zram0: detected capacity change from 0 to 402653184
> > [ 7.667702] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 across:393212k SS
> >
> > ... delay due to other causes ...
> >
> > [ 28.640234] dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/10Mbps/Full
> > [ 28.640295] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/10Mbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
> > [ 28.640324] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx
> >
> > Settings for eth0:
> > Supported ports: [ TP MII ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > Supported pause frame use: Symmetric Receive-only
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > Advertised pause frame use: Symmetric Receive-only
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > Link partner advertised pause frame use: Symmetric Receive-only
> > Link partner advertised auto-negotiation: Yes
> > Link partner advertised FEC modes: Not reported
> > Speed: 10Mb/s
> > Duplex: Full
> > Port: MII
> > PHYAD: 1
> > Transceiver: internal
> > Auto-negotiation: on
> > Supports Wake-on: d
> > Wake-on: d
> > Current message level: 0x0000003f (63)
> > drv probe link timer ifdown ifup
> > Link detected: yes
> >
> > On 5.2 it looks like this:
> >
> > [ 1.153596] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> > [ 1.416221] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> > [ 1.522735] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
> > [ 1.522750] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
> > [ 1.522753] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
> > [ 1.522755] dwmac-sun8i 5020000.ethernet: COE Type 2
> > [ 1.522758] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
> > [ 1.522761] dwmac-sun8i 5020000.ethernet: Normal descriptors
> > [ 1.522763] dwmac-sun8i 5020000.ethernet: Chain mode enabled
> > [ 5.352833] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> > [ 5.352842] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> > [ 5.352846] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> > [ 10.463072] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> >
> > Settings for eth0:
> > Supported ports: [ TP MII ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Half 1000baseT/Full
> > Supported pause frame use: Symmetric Receive-only
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Half 1000baseT/Full
> > Advertised pause frame use: No
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Link partner advertised pause frame use: Symmetric Receive-only
> > Link partner advertised auto-negotiation: Yes
> > Link partner advertised FEC modes: Not reported
> > Speed: 1000Mb/s
> > Duplex: Full
> > Port: MII
> > PHYAD: 1
> > Transceiver: internal
> > Auto-negotiation: on
> > Supports Wake-on: d
> > Wake-on: d
> > Current message level: 0x0000003f (63)
> > drv probe link timer ifdown ifup
> > Link detected: yes
> >
> >
> > > Cc: Joao Pinto <[email protected]>
> > > Cc: David S. Miller <[email protected]>
> > > Cc: Giuseppe Cavallaro <[email protected]>
> > > Cc: Alexandre Torgue <[email protected]>
> > > Cc: Russell King <[email protected]>
> > > Cc: Andrew Lunn <[email protected]>
> > > Cc: Florian Fainelli <[email protected]>
> > > Cc: Heiner Kallweit <[email protected]>
> > >
> > > Jose Abreu (3):
> > > net: stmmac: Prepare to convert to phylink
> > > net: stmmac: Start adding phylink support
> > > net: stmmac: Convert to phylink and remove phylib logic
> > >
> > > drivers/net/ethernet/stmicro/stmmac/Kconfig | 3 +-
> > > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +-
> > > .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +---
> > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 391 ++++++++----------
> > > .../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +-
> > > 5 files changed, 190 insertions(+), 313 deletions(-)
> > >
> > > --
> > > 2.21.0
> > >
>
>
> ---
> Thanks,
> Jose Miguel Abreu



Attachments:
(No filename) (8.14 kB)
signature.asc (235.00 B)
Download all attachments

2019-07-22 17:26:58

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink

On Mon, Jul 22, 2019 at 01:58:20PM +0000, Jose Abreu wrote:
> From: Andrew Lunn <[email protected]>
> Date: Jul/22/2019, 14:40:23 (UTC+00:00)
>
> > Does this mean that all stmmac variants support 1G? There are none
> > which just support Fast Ethernet?
>
> This glue logic drivers sometimes reflect a custom IP that's Synopsys
> based but modified by customer, so I can't know before-hand what's the
> supported max speed. There are some old versions that don't support 1G
> but I expect that PHY driver limits this ...

If a Fast PHY is used, then yes, it would be limited. But sometimes a
1G PHY is used because they are cheaper than a Fast PHY.

> > I'm also not sure the change fits the problem. Why did it not
> > negotiate 100FULL rather than 10Half? You are only moving the 1G
> > speeds around, so 100 speeds should of been advertised and selected.
>
> Hmm, now that I'm looking at it closer I agree with you. Maybe link
> partner or PHY doesn't support 100M ?

In the working case, ethtool shows the link partner supports 10, 100,
and 1G. So something odd is going on here.

You fix does seems reasonable, and it has been reported to fix the
issue, but it would be good to understand what is going on here.

Andrew

2019-07-22 17:29:25

by Ondřej Jirman

[permalink] [raw]
Subject: Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink

On Mon, Jul 22, 2019 at 02:26:45PM +0000, Jose Abreu wrote:
> From: Andrew Lunn <[email protected]>
> Date: Jul/22/2019, 15:19:43 (UTC+00:00)
>
> > On Mon, Jul 22, 2019 at 01:58:20PM +0000, Jose Abreu wrote:
> > > From: Andrew Lunn <[email protected]>
> > > Date: Jul/22/2019, 14:40:23 (UTC+00:00)
> > >
> > > > Does this mean that all stmmac variants support 1G? There are none
> > > > which just support Fast Ethernet?
> > >
> > > This glue logic drivers sometimes reflect a custom IP that's Synopsys
> > > based but modified by customer, so I can't know before-hand what's the
> > > supported max speed. There are some old versions that don't support 1G
> > > but I expect that PHY driver limits this ...
> >
> > If a Fast PHY is used, then yes, it would be limited. But sometimes a
> > 1G PHY is used because they are cheaper than a Fast PHY.
> >
> > > > I'm also not sure the change fits the problem. Why did it not
> > > > negotiate 100FULL rather than 10Half? You are only moving the 1G
> > > > speeds around, so 100 speeds should of been advertised and selected.
> > >
> > > Hmm, now that I'm looking at it closer I agree with you. Maybe link
> > > partner or PHY doesn't support 100M ?
> >
> > In the working case, ethtool shows the link partner supports 10, 100,
> > and 1G. So something odd is going on here.
> >
> > You fix does seems reasonable, and it has been reported to fix the
> > issue, but it would be good to understand what is going on here.
>
> Agreed!
>
> Ondrej, can you please share dmesg log and ethtool output with the fixed
> patch ?

See the attachment, or this link:

https://megous.com/dl/tmp/dmesg-5.3-working

regards,
Ondrej

> ---
> Thanks,
> Jose Miguel Abreu


Attachments:
(No filename) (1.72 kB)
dmesg-5.3-working (32.18 kB)
Download all attachments

2019-07-22 18:52:43

by Jose Abreu

[permalink] [raw]
Subject: RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink

From: Andrew Lunn <[email protected]>
Date: Jul/22/2019, 15:19:43 (UTC+00:00)

> On Mon, Jul 22, 2019 at 01:58:20PM +0000, Jose Abreu wrote:
> > From: Andrew Lunn <[email protected]>
> > Date: Jul/22/2019, 14:40:23 (UTC+00:00)
> >
> > > Does this mean that all stmmac variants support 1G? There are none
> > > which just support Fast Ethernet?
> >
> > This glue logic drivers sometimes reflect a custom IP that's Synopsys
> > based but modified by customer, so I can't know before-hand what's the
> > supported max speed. There are some old versions that don't support 1G
> > but I expect that PHY driver limits this ...
>
> If a Fast PHY is used, then yes, it would be limited. But sometimes a
> 1G PHY is used because they are cheaper than a Fast PHY.
>
> > > I'm also not sure the change fits the problem. Why did it not
> > > negotiate 100FULL rather than 10Half? You are only moving the 1G
> > > speeds around, so 100 speeds should of been advertised and selected.
> >
> > Hmm, now that I'm looking at it closer I agree with you. Maybe link
> > partner or PHY doesn't support 100M ?
>
> In the working case, ethtool shows the link partner supports 10, 100,
> and 1G. So something odd is going on here.
>
> You fix does seems reasonable, and it has been reported to fix the
> issue, but it would be good to understand what is going on here.

Agreed!

Ondrej, can you please share dmesg log and ethtool output with the fixed
patch ?

---
Thanks,
Jose Miguel Abreu

2019-07-23 15:39:39

by Jose Abreu

[permalink] [raw]
Subject: RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink

From: Ond?ej Jirman <[email protected]>
Date: Jul/22/2019, 15:39:55 (UTC+00:00)

> On Mon, Jul 22, 2019 at 02:26:45PM +0000, Jose Abreu wrote:
> > From: Andrew Lunn <[email protected]>
> > Date: Jul/22/2019, 15:19:43 (UTC+00:00)
> >
> > > On Mon, Jul 22, 2019 at 01:58:20PM +0000, Jose Abreu wrote:
> > > > From: Andrew Lunn <[email protected]>
> > > > Date: Jul/22/2019, 14:40:23 (UTC+00:00)
> > > >
> > > > > Does this mean that all stmmac variants support 1G? There are none
> > > > > which just support Fast Ethernet?
> > > >
> > > > This glue logic drivers sometimes reflect a custom IP that's Synopsys
> > > > based but modified by customer, so I can't know before-hand what's the
> > > > supported max speed. There are some old versions that don't support 1G
> > > > but I expect that PHY driver limits this ...
> > >
> > > If a Fast PHY is used, then yes, it would be limited. But sometimes a
> > > 1G PHY is used because they are cheaper than a Fast PHY.
> > >
> > > > > I'm also not sure the change fits the problem. Why did it not
> > > > > negotiate 100FULL rather than 10Half? You are only moving the 1G
> > > > > speeds around, so 100 speeds should of been advertised and selected.
> > > >
> > > > Hmm, now that I'm looking at it closer I agree with you. Maybe link
> > > > partner or PHY doesn't support 100M ?
> > >
> > > In the working case, ethtool shows the link partner supports 10, 100,
> > > and 1G. So something odd is going on here.
> > >
> > > You fix does seems reasonable, and it has been reported to fix the
> > > issue, but it would be good to understand what is going on here.
> >
> > Agreed!
> >
> > Ondrej, can you please share dmesg log and ethtool output with the fixed
> > patch ?
>
> See the attachment, or this link:

So, I've removed all 1G link modes from stmmac and run it on an ARM
based board. My link status resolves to 100M/Full using Generic PHY so
maybe something is wrong with the PHY driver that Ondrej is using
("RTL8211E Gigabit Ethernet") ?

---
Thanks,
Jose Miguel Abreu