2018-03-16 10:41:12

by Antoine Tenart

[permalink] [raw]
Subject: [PATCH net-next 00/10] net: mvpp2: phylink conversion

Hi Dave, Russell,

This series convert the Marvell PPv2 driver to phylink (models the MAC
to PHY link). The series is a respin of a patch[1] and a series[2] sent
a while ago. All these patches have been heavily reworked, this is why
this series isn't a new version of the previous work. I still tried to
take in account the comments I got back then (when applicable).

One important point is the PPv2 driver supports two probe modes: device
tree and ACPI. This series only brings phylink support for the device
tree mode, as the ACPI one will need further work. Still, the driver
should be working as before when using ACPI. This split should be
temporary, and was discussed with Marcin (in Cc.) who added ACPI support
to the driver.

Before implementing phylink callbacks in the PPv2 driver, some patches
are required (patches 1 and 2). The first one is a cosmetic patch, the
other one modifies the phylink core. Then PPv2 is converted to phylink.

The rest of the series uses phylink to add support for 1000BaseX and
2500BaseX modes in the PPv2 driver. To do this, two patches are needed
in the common PHY framework (patches 4 and 5). These patches were
previously acked by Kishon but as this was a while ago I didn't kept the
tags. The last 3 patches modify the device tree to use the new PPv2
functionalities.

@Dave: patches 8 to 10 should go through the mvebu tree (Gregory in Cc.)
to avoid any conflict with the other mvebu dt patches taken during this
cycle.

The series has been tested for the device tree mode on the 7040-db,
8040-db and 8040-mcbin boards, to ensure all the interface where working
as expected. Marcin (in Cc.) tested the series for the ACPI mode.

The series is based on today's net-next, and is available at:
https://github.com/MISL-EBU-System-SW/mainline-public/ at/net-next/ppv2-phylink

Thanks!
Antoine

[1] http://www.spinics.net/lists/netdev/msg456023.html
[2] https://lkml.org/lkml/2018/1/12/59

Antoine Tenart (10):
net: mvpp2: align the ethtool ops definition
net: phy: phylink: allow 10GKR interface to use in-band negotiation
net: mvpp2: phylink support
phy: add 2.5G SGMII mode to the phy_mode enum
phy: cp110-comphy: 2.5G SGMII mode
net: mvpp2: 1000baseX support
net: mvpp2: 2500baseX support
arm64: dts: marvell: 7040-db: set the 10G interface management to
in-band
arm64: dts: marvell: 8040-db: set the 10G interfaces management to
in-band
arm64: dts: marvell: mcbin: enable the fourth network interface

arch/arm64/boot/dts/marvell/armada-7040-db.dts | 1 +
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 2 +
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 11 +
drivers/net/ethernet/marvell/Kconfig | 1 +
drivers/net/ethernet/marvell/mvpp2.c | 917 +++++++++++++---------
drivers/net/phy/phylink.c | 3 +-
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 +-
include/linux/phy/phy.h | 1 +
8 files changed, 599 insertions(+), 354 deletions(-)

--
2.14.3



2018-03-16 10:37:16

by Antoine Tenart

[permalink] [raw]
Subject: [PATCH net-next 09/10] arm64: dts: marvell: 8040-db: set the 10G interfaces management to in-band

This patch sets the 10G interfaces (cp0_eth0, cp1_eth0) management to
in-band. This is needed for the PPv2 driver to handle such ports, with
its conversion to phylink.

Signed-off-by: Antoine Tenart <[email protected]>
---
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
index dba55baff20f..f6224d323c7a 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -216,6 +216,7 @@
&cp0_eth0 {
status = "okay";
phy-mode = "10gbase-kr";
+ managed = "in-band-status";
};

&cp0_eth2 {
@@ -334,6 +335,7 @@
&cp1_eth0 {
status = "okay";
phy-mode = "10gbase-kr";
+ managed = "in-band-status";
};

&cp1_eth1 {
--
2.14.3


2018-03-16 10:38:20

by Antoine Tenart

[permalink] [raw]
Subject: [PATCH net-next 08/10] arm64: dts: marvell: 7040-db: set the 10G interface management to in-band

This patch sets the 10G interface (cp0_eth0) management to in-band. This
is needed for the PPv2 driver to handle such ports, with its conversion
to phylink.

Signed-off-by: Antoine Tenart <[email protected]>
---
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
index 3ae05eee2c9a..f27af07db381 100644
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -267,6 +267,7 @@
status = "okay";
/* Network PHY */
phy-mode = "10gbase-kr";
+ managed = "in-band-status";
/* Generic PHY, providing serdes lanes */
phys = <&cp0_comphy2 0>;
};
--
2.14.3


2018-03-16 10:38:23

by Antoine Tenart

[permalink] [raw]
Subject: [PATCH net-next 03/10] net: mvpp2: phylink support

Convert the PPv2 driver to implement phylink helpers, and use phylink in
DT mode. The other mode supported is ACPI, which will need further work
in order to be entirely compatible with phylink.

The MAC and GoP configuration functions were completely moved to fit
into the phylink helpers. When a PHY is always present between the MAC
and the physical port, phylink only is used, but when this is not the
case (the MAC directly is connected to the physical port) the link IRQ
is used to detect changes in the link state and call phylink_mac_change.

The ACPI mode do not uses phylink as of now, and the changes shouldn't
impact its use.

Signed-off-by: Antoine Tenart <[email protected]>
---
drivers/net/ethernet/marvell/Kconfig | 1 +
drivers/net/ethernet/marvell/mvpp2.c | 832 +++++++++++++++++++++--------------
2 files changed, 497 insertions(+), 336 deletions(-)

diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
index ebe5c9148935..cc2f7701e71e 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -86,6 +86,7 @@ config MVPP2
depends on ARCH_MVEBU || COMPILE_TEST
depends on HAS_DMA
select MVMDIO
+ select PHYLINK
---help---
This driver supports the network interface units in the
Marvell ARMADA 375, 7K and 8K SoCs.
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 430114ad93fc..8e8e7afcd437 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -29,6 +29,7 @@
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/phy.h>
+#include <linux/phylink.h>
#include <linux/phy/phy.h>
#include <linux/clk.h>
#include <linux/hrtimer.h>
@@ -359,15 +360,23 @@
#define MVPP2_GMAC_FORCE_LINK_PASS BIT(1)
#define MVPP2_GMAC_IN_BAND_AUTONEG BIT(2)
#define MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS BIT(3)
+#define MVPP2_GMAC_IN_BAND_RESTART_AN BIT(4)
#define MVPP2_GMAC_CONFIG_MII_SPEED BIT(5)
#define MVPP2_GMAC_CONFIG_GMII_SPEED BIT(6)
#define MVPP2_GMAC_AN_SPEED_EN BIT(7)
#define MVPP2_GMAC_FC_ADV_EN BIT(9)
+#define MVPP2_GMAC_FC_ADV_ASM_EN BIT(10)
#define MVPP2_GMAC_FLOW_CTRL_AUTONEG BIT(11)
#define MVPP2_GMAC_CONFIG_FULL_DUPLEX BIT(12)
#define MVPP2_GMAC_AN_DUPLEX_EN BIT(13)
#define MVPP2_GMAC_STATUS0 0x10
#define MVPP2_GMAC_STATUS0_LINK_UP BIT(0)
+#define MVPP2_GMAC_STATUS0_GMII_SPEED BIT(1)
+#define MVPP2_GMAC_STATUS0_MII_SPEED BIT(2)
+#define MVPP2_GMAC_STATUS0_FULL_DUPLEX BIT(3)
+#define MVPP2_GMAC_STATUS0_RX_PAUSE BIT(6)
+#define MVPP2_GMAC_STATUS0_TX_PAUSE BIT(7)
+#define MVPP2_GMAC_STATUS0_AN_COMPLETE BIT(11)
#define MVPP2_GMAC_PORT_FIFO_CFG_1_REG 0x1c
#define MVPP2_GMAC_TX_FIFO_MIN_TH_OFFS 6
#define MVPP2_GMAC_TX_FIFO_MIN_TH_ALL_MASK 0x1fc0
@@ -379,6 +388,8 @@
#define MVPP22_GMAC_INT_MASK_LINK_STAT BIT(1)
#define MVPP22_GMAC_CTRL_4_REG 0x90
#define MVPP22_CTRL4_EXT_PIN_GMII_SEL BIT(0)
+#define MVPP22_CTRL4_RX_FC_EN BIT(3)
+#define MVPP22_CTRL4_TX_FC_EN BIT(4)
#define MVPP22_CTRL4_DP_CLK_SEL BIT(5)
#define MVPP22_CTRL4_SYNC_BYPASS_DIS BIT(6)
#define MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE BIT(7)
@@ -392,6 +403,7 @@
#define MVPP22_XLG_CTRL0_PORT_EN BIT(0)
#define MVPP22_XLG_CTRL0_MAC_RESET_DIS BIT(1)
#define MVPP22_XLG_CTRL0_RX_FLOW_CTRL_EN BIT(7)
+#define MVPP22_XLG_CTRL0_TX_FLOW_CTRL_EN BIT(8)
#define MVPP22_XLG_CTRL0_MIB_CNT_DIS BIT(14)
#define MVPP22_XLG_CTRL1_REG 0x104
#define MVPP22_XLG_CTRL1_FRAMESIZELIMIT_OFFS 0
@@ -1014,6 +1026,9 @@ struct mvpp2_port {
/* Firmware node associated to the port */
struct fwnode_handle *fwnode;

+ /* Is a PHY always connected to the port */
+ bool has_phy;
+
/* Per-port registers' base address */
void __iomem *base;
void __iomem *stats_base;
@@ -1041,12 +1056,11 @@ struct mvpp2_port {
struct mutex gather_stats_lock;
struct delayed_work stats_work;

+ struct device_node *of_node;
+
phy_interface_t phy_interface;
- struct device_node *phy_node;
+ struct phylink *phylink;
struct phy *comphy;
- unsigned int link;
- unsigned int duplex;
- unsigned int speed;

struct mvpp2_bm_pool *pool_long;
struct mvpp2_bm_pool *pool_short;
@@ -1335,6 +1349,12 @@ struct mvpp2_bm_pool {
(addr) < (txq_pcpu)->tso_headers_dma + \
(txq_pcpu)->size * TSO_HEADER_SIZE)

+/* The prototype is added here to be used in start_dev when using ACPI. This
+ * will be removed once phylink is used for all modes (dt+ACPI).
+ */
+static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
+ const struct phylink_link_state *state);
+
/* Queue modes */
#define MVPP2_QDIST_SINGLE_MODE 0
#define MVPP2_QDIST_MULTI_MODE 1
@@ -4996,133 +5016,6 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
return phy_power_on(port->comphy);
}

-static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
-{
- u32 val;
-
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
- val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
- val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
- MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
- val &= ~MVPP22_CTRL4_EXT_PIN_GMII_SEL;
- writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
- } else if (phy_interface_mode_is_rgmii(port->phy_interface)) {
- val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
- val |= MVPP22_CTRL4_EXT_PIN_GMII_SEL |
- MVPP22_CTRL4_SYNC_BYPASS_DIS |
- MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
- val &= ~MVPP22_CTRL4_DP_CLK_SEL;
- writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
- }
-
- /* The port is connected to a copper PHY */
- val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
- val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
- writel(val, port->base + MVPP2_GMAC_CTRL_0_REG);
-
- val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val |= MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS |
- MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_FLOW_CTRL_AUTONEG |
- MVPP2_GMAC_AN_DUPLEX_EN;
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
- val |= MVPP2_GMAC_IN_BAND_AUTONEG;
- writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
-}
-
-static void mvpp2_port_mii_gmac_configure(struct mvpp2_port *port)
-{
- u32 val;
-
- /* Force link down */
- val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val &= ~MVPP2_GMAC_FORCE_LINK_PASS;
- val |= MVPP2_GMAC_FORCE_LINK_DOWN;
- writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
-
- /* Set the GMAC in a reset state */
- val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
- val |= MVPP2_GMAC_PORT_RESET_MASK;
- writel(val, port->base + MVPP2_GMAC_CTRL_2_REG);
-
- /* Configure the PCS and in-band AN */
- val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
- val |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;
- } else if (phy_interface_mode_is_rgmii(port->phy_interface)) {
- val &= ~MVPP2_GMAC_PCS_ENABLE_MASK;
- }
- writel(val, port->base + MVPP2_GMAC_CTRL_2_REG);
-
- mvpp2_port_mii_gmac_configure_mode(port);
-
- /* Unset the GMAC reset state */
- val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
- val &= ~MVPP2_GMAC_PORT_RESET_MASK;
- writel(val, port->base + MVPP2_GMAC_CTRL_2_REG);
-
- /* Stop forcing link down */
- val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val &= ~MVPP2_GMAC_FORCE_LINK_DOWN;
- writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
-}
-
-static void mvpp2_port_mii_xlg_configure(struct mvpp2_port *port)
-{
- u32 val;
-
- if (port->gop_id != 0)
- return;
-
- val = readl(port->base + MVPP22_XLG_CTRL0_REG);
- val |= MVPP22_XLG_CTRL0_RX_FLOW_CTRL_EN;
- writel(val, port->base + MVPP22_XLG_CTRL0_REG);
-
- val = readl(port->base + MVPP22_XLG_CTRL4_REG);
- val &= ~MVPP22_XLG_CTRL4_MACMODSELECT_GMAC;
- val |= MVPP22_XLG_CTRL4_FWD_FC | MVPP22_XLG_CTRL4_FWD_PFC;
- writel(val, port->base + MVPP22_XLG_CTRL4_REG);
-}
-
-static void mvpp22_port_mii_set(struct mvpp2_port *port)
-{
- u32 val;
-
- /* Only GOP port 0 has an XLG MAC */
- if (port->gop_id == 0) {
- val = readl(port->base + MVPP22_XLG_CTRL3_REG);
- val &= ~MVPP22_XLG_CTRL3_MACMODESELECT_MASK;
-
- if (port->phy_interface == PHY_INTERFACE_MODE_XAUI ||
- port->phy_interface == PHY_INTERFACE_MODE_10GKR)
- val |= MVPP22_XLG_CTRL3_MACMODESELECT_10G;
- else
- val |= MVPP22_XLG_CTRL3_MACMODESELECT_GMAC;
-
- writel(val, port->base + MVPP22_XLG_CTRL3_REG);
- }
-}
-
-static void mvpp2_port_mii_set(struct mvpp2_port *port)
-{
- if (port->priv->hw_version == MVPP22)
- mvpp22_port_mii_set(port);
-
- if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII)
- mvpp2_port_mii_gmac_configure(port);
- else if (port->phy_interface == PHY_INTERFACE_MODE_10GKR)
- mvpp2_port_mii_xlg_configure(port);
-}
-
-static void mvpp2_port_fc_adv_enable(struct mvpp2_port *port)
-{
- u32 val;
-
- val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val |= MVPP2_GMAC_FC_ADV_EN;
- writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
-}
-
static void mvpp2_port_enable(struct mvpp2_port *port)
{
u32 val;
@@ -5174,13 +5067,14 @@ static void mvpp2_port_periodic_xon_disable(struct mvpp2_port *port)
}

/* Configure loopback port */
-static void mvpp2_port_loopback_set(struct mvpp2_port *port)
+static void mvpp2_port_loopback_set(struct mvpp2_port *port,
+ const struct phylink_link_state *state)
{
u32 val;

val = readl(port->base + MVPP2_GMAC_CTRL_1_REG);

- if (port->speed == 1000)
+ if (state->speed == 1000)
val |= MVPP2_GMAC_GMII_LB_EN_MASK;
else
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;
@@ -5358,10 +5252,6 @@ static void mvpp2_defaults_set(struct mvpp2_port *port)
int tx_port_num, val, queue, ptxq, lrxq;

if (port->priv->hw_version == MVPP21) {
- /* Configure port to loopback if needed */
- if (port->flags & MVPP2_F_LOOPBACK)
- mvpp2_port_loopback_set(port);
-
/* Update TX FIFO MIN Threshold */
val = readl(port->base + MVPP2_GMAC_PORT_FIFO_CFG_1_REG);
val &= ~MVPP2_GMAC_TX_FIFO_MIN_TH_ALL_MASK;
@@ -6408,6 +6298,11 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
}
}

+ if (port->phylink) {
+ phylink_mac_change(port->phylink, link);
+ goto handled;
+ }
+
if (!netif_running(dev) || !event)
goto handled;

@@ -6432,111 +6327,6 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}

-static void mvpp2_gmac_set_autoneg(struct mvpp2_port *port,
- struct phy_device *phydev)
-{
- u32 val;
-
- if (port->phy_interface != PHY_INTERFACE_MODE_RGMII &&
- port->phy_interface != PHY_INTERFACE_MODE_RGMII_ID &&
- port->phy_interface != PHY_INTERFACE_MODE_RGMII_RXID &&
- port->phy_interface != PHY_INTERFACE_MODE_RGMII_TXID &&
- port->phy_interface != PHY_INTERFACE_MODE_SGMII)
- return;
-
- val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val &= ~(MVPP2_GMAC_CONFIG_MII_SPEED |
- MVPP2_GMAC_CONFIG_GMII_SPEED |
- MVPP2_GMAC_CONFIG_FULL_DUPLEX |
- MVPP2_GMAC_AN_SPEED_EN |
- MVPP2_GMAC_AN_DUPLEX_EN);
-
- if (phydev->duplex)
- val |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
-
- if (phydev->speed == SPEED_1000)
- val |= MVPP2_GMAC_CONFIG_GMII_SPEED;
- else if (phydev->speed == SPEED_100)
- val |= MVPP2_GMAC_CONFIG_MII_SPEED;
-
- writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
-}
-
-/* Adjust link */
-static void mvpp2_link_event(struct net_device *dev)
-{
- struct mvpp2_port *port = netdev_priv(dev);
- struct phy_device *phydev = dev->phydev;
- bool link_reconfigured = false;
- u32 val;
-
- if (phydev->link) {
- if (port->phy_interface != phydev->interface && port->comphy) {
- /* disable current port for reconfiguration */
- mvpp2_interrupts_disable(port);
- netif_carrier_off(port->dev);
- mvpp2_port_disable(port);
- phy_power_off(port->comphy);
-
- /* comphy reconfiguration */
- port->phy_interface = phydev->interface;
- mvpp22_comphy_init(port);
-
- /* gop/mac reconfiguration */
- mvpp22_gop_init(port);
- mvpp2_port_mii_set(port);
-
- link_reconfigured = true;
- }
-
- if ((port->speed != phydev->speed) ||
- (port->duplex != phydev->duplex)) {
- mvpp2_gmac_set_autoneg(port, phydev);
-
- port->duplex = phydev->duplex;
- port->speed = phydev->speed;
- }
- }
-
- if (phydev->link != port->link || link_reconfigured) {
- port->link = phydev->link;
-
- if (phydev->link) {
- if (port->phy_interface == PHY_INTERFACE_MODE_RGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_RGMII_ID ||
- port->phy_interface == PHY_INTERFACE_MODE_RGMII_RXID ||
- port->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
- val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val |= (MVPP2_GMAC_FORCE_LINK_PASS |
- MVPP2_GMAC_FORCE_LINK_DOWN);
- writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- }
-
- mvpp2_interrupts_enable(port);
- mvpp2_port_enable(port);
-
- mvpp2_egress_enable(port);
- mvpp2_ingress_enable(port);
- netif_carrier_on(dev);
- netif_tx_wake_all_queues(dev);
- } else {
- port->duplex = -1;
- port->speed = 0;
-
- netif_tx_stop_all_queues(dev);
- netif_carrier_off(dev);
- mvpp2_ingress_disable(port);
- mvpp2_egress_disable(port);
-
- mvpp2_port_disable(port);
- mvpp2_interrupts_disable(port);
- }
-
- phy_print_status(phydev);
- }
-}
-
static void mvpp2_timer_set(struct mvpp2_port_pcpu *port_pcpu)
{
ktime_t interval;
@@ -7144,11 +6934,29 @@ static int mvpp2_poll(struct napi_struct *napi, int budget)
return rx_done;
}

-/* Set hw internals when starting port */
-static void mvpp2_start_dev(struct mvpp2_port *port)
+static void mvpp22_mode_reconfigure(struct mvpp2_port *port)
{
- struct net_device *ndev = port->dev;
- int i;
+ u32 ctrl3;
+
+ /* comphy reconfiguration */
+ mvpp22_comphy_init(port);
+
+ /* gop reconfiguration */
+ mvpp22_gop_init(port);
+
+ /* Only GOP port 0 has an XLG MAC */
+ if (port->gop_id == 0) {
+ ctrl3 = readl(port->base + MVPP22_XLG_CTRL3_REG);
+ ctrl3 &= ~MVPP22_XLG_CTRL3_MACMODESELECT_MASK;
+
+ if (port->phy_interface == PHY_INTERFACE_MODE_XAUI ||
+ port->phy_interface == PHY_INTERFACE_MODE_10GKR)
+ ctrl3 |= MVPP22_XLG_CTRL3_MACMODESELECT_10G;
+ else
+ ctrl3 |= MVPP22_XLG_CTRL3_MACMODESELECT_GMAC;
+
+ writel(ctrl3, port->base + MVPP22_XLG_CTRL3_REG);
+ }

if (port->gop_id == 0 &&
(port->phy_interface == PHY_INTERFACE_MODE_XAUI ||
@@ -7156,6 +6964,12 @@ static void mvpp2_start_dev(struct mvpp2_port *port)
mvpp2_xlg_max_rx_size_set(port);
else
mvpp2_gmac_max_rx_size_set(port);
+}
+
+/* Set hw internals when starting port */
+static void mvpp2_start_dev(struct mvpp2_port *port)
+{
+ int i;

mvpp2_txp_max_tx_size_set(port);

@@ -7165,42 +6979,39 @@ static void mvpp2_start_dev(struct mvpp2_port *port)
/* Enable interrupts on all CPUs */
mvpp2_interrupts_enable(port);

- if (port->priv->hw_version == MVPP22) {
- mvpp22_comphy_init(port);
- mvpp22_gop_init(port);
+ if (port->priv->hw_version == MVPP22)
+ mvpp22_mode_reconfigure(port);
+
+ if (port->phylink) {
+ phylink_start(port->phylink);
+ } else {
+ /* Phylink isn't used as of now for ACPI, so the MAC has to be
+ * configured manually when the interface is started. This will
+ * be removed as soon as the phylink ACPI support lands in.
+ */
+ struct phylink_link_state state = {
+ .interface = port->phy_interface,
+ .link = 1,
+ };
+ mvpp2_mac_config(port->dev, MLO_AN_INBAND, &state);
}

- mvpp2_port_mii_set(port);
- mvpp2_port_enable(port);
- if (ndev->phydev)
- phy_start(ndev->phydev);
netif_tx_start_all_queues(port->dev);
}

/* Set hw internals when stopping port */
static void mvpp2_stop_dev(struct mvpp2_port *port)
{
- struct net_device *ndev = port->dev;
int i;

- /* Stop new packets from arriving to RXQs */
- mvpp2_ingress_disable(port);
-
- mdelay(10);
-
/* Disable interrupts on all CPUs */
mvpp2_interrupts_disable(port);

for (i = 0; i < port->nqvecs; i++)
napi_disable(&port->qvecs[i].napi);

- netif_carrier_off(port->dev);
- netif_tx_stop_all_queues(port->dev);
-
- mvpp2_egress_disable(port);
- mvpp2_port_disable(port);
- if (ndev->phydev)
- phy_stop(ndev->phydev);
+ if (port->phylink)
+ phylink_stop(port->phylink);
phy_power_off(port->comphy);
}

@@ -7259,40 +7070,6 @@ static void mvpp21_get_mac_address(struct mvpp2_port *port, unsigned char *addr)
addr[5] = (mac_addr_l >> MVPP2_GMAC_SA_LOW_OFFS) & 0xFF;
}

-static int mvpp2_phy_connect(struct mvpp2_port *port)
-{
- struct phy_device *phy_dev;
-
- /* No PHY is attached */
- if (!port->phy_node)
- return 0;
-
- phy_dev = of_phy_connect(port->dev, port->phy_node, mvpp2_link_event, 0,
- port->phy_interface);
- if (!phy_dev) {
- netdev_err(port->dev, "cannot connect to phy\n");
- return -ENODEV;
- }
- phy_dev->supported &= PHY_GBIT_FEATURES;
- phy_dev->advertising = phy_dev->supported;
-
- port->link = 0;
- port->duplex = 0;
- port->speed = 0;
-
- return 0;
-}
-
-static void mvpp2_phy_disconnect(struct mvpp2_port *port)
-{
- struct net_device *ndev = port->dev;
-
- if (!ndev->phydev)
- return;
-
- phy_disconnect(ndev->phydev);
-}
-
static int mvpp2_irqs_init(struct mvpp2_port *port)
{
int err, i;
@@ -7376,6 +7153,7 @@ static int mvpp2_open(struct net_device *dev)
struct mvpp2 *priv = port->priv;
unsigned char mac_bcast[ETH_ALEN] = {
0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
+ bool valid = false;
int err;

err = mvpp2_prs_mac_da_accept(port, mac_bcast, true);
@@ -7418,7 +7196,20 @@ static int mvpp2_open(struct net_device *dev)
goto err_cleanup_txqs;
}

- if (priv->hw_version == MVPP22 && !port->phy_node && port->link_irq) {
+ /* Phylink isn't supported yet in ACPI mode */
+ if (port->of_node) {
+ err = phylink_of_phy_connect(port->phylink, port->of_node, 0);
+ if (err) {
+ netdev_err(port->dev, "could not attach PHY (%d)\n",
+ err);
+ goto err_free_irq;
+ }
+
+ valid = true;
+ }
+
+ if (priv->hw_version == MVPP22 && port->link_irq &&
+ (!port->phylink || !port->has_phy)) {
err = request_irq(port->link_irq, mvpp2_link_status_isr, 0,
dev->name, port);
if (err) {
@@ -7428,14 +7219,20 @@ static int mvpp2_open(struct net_device *dev)
}

mvpp22_gop_setup_irq(port);
- }

- /* In default link is down */
- netif_carrier_off(port->dev);
+ /* In default link is down */
+ netif_carrier_off(port->dev);

- err = mvpp2_phy_connect(port);
- if (err < 0)
- goto err_free_link_irq;
+ valid = true;
+ } else {
+ port->link_irq = 0;
+ }
+
+ if (!valid) {
+ netdev_err(port->dev,
+ "invalid configuration: no dt or link IRQ");
+ goto err_free_irq;
+ }

/* Unmask interrupts on all CPUs */
on_each_cpu(mvpp2_interrupts_unmask, port, 1);
@@ -7452,9 +7249,6 @@ static int mvpp2_open(struct net_device *dev)

return 0;

-err_free_link_irq:
- if (priv->hw_version == MVPP22 && !port->phy_node && port->link_irq)
- free_irq(port->link_irq, port);
err_free_irq:
mvpp2_irqs_deinit(port);
err_cleanup_txqs:
@@ -7468,17 +7262,17 @@ static int mvpp2_stop(struct net_device *dev)
{
struct mvpp2_port *port = netdev_priv(dev);
struct mvpp2_port_pcpu *port_pcpu;
- struct mvpp2 *priv = port->priv;
int cpu;

mvpp2_stop_dev(port);
- mvpp2_phy_disconnect(port);

/* Mask interrupts on all CPUs */
on_each_cpu(mvpp2_interrupts_mask, port, 1);
mvpp2_shared_interrupt_mask_unmask(port, true);

- if (priv->hw_version == MVPP22 && !port->phy_node && port->link_irq)
+ if (port->phylink)
+ phylink_disconnect_phy(port->phylink);
+ if (port->link_irq)
free_irq(port->link_irq, port);

mvpp2_irqs_deinit(port);
@@ -7684,16 +7478,12 @@ mvpp2_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *stats)

static int mvpp2_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
- int ret;
+ struct mvpp2_port *port = netdev_priv(dev);

- if (!dev->phydev)
+ if (!port->phylink)
return -ENOTSUPP;

- ret = phy_mii_ioctl(dev->phydev, ifr, cmd);
- if (!ret)
- mvpp2_link_event(dev);
-
- return ret;
+ return phylink_mii_ioctl(port->phylink, ifr, cmd);
}

static int mvpp2_vlan_rx_add_vid(struct net_device *dev, __be16 proto, u16 vid)
@@ -7740,6 +7530,16 @@ static int mvpp2_set_features(struct net_device *dev,

/* Ethtool methods */

+static int mvpp2_ethtool_nway_reset(struct net_device *dev)
+{
+ struct mvpp2_port *port = netdev_priv(dev);
+
+ if (!port->phylink)
+ return -ENOTSUPP;
+
+ return phylink_ethtool_nway_reset(port->phylink);
+}
+
/* Set interrupt coalescing for ethtools */
static int mvpp2_ethtool_set_coalesce(struct net_device *dev,
struct ethtool_coalesce *c)
@@ -7868,6 +7668,50 @@ static int mvpp2_ethtool_set_ringparam(struct net_device *dev,
return err;
}

+static void mvpp2_ethtool_get_pause_param(struct net_device *dev,
+ struct ethtool_pauseparam *pause)
+{
+ struct mvpp2_port *port = netdev_priv(dev);
+
+ if (!port->phylink)
+ return;
+
+ phylink_ethtool_get_pauseparam(port->phylink, pause);
+}
+
+static int mvpp2_ethtool_set_pause_param(struct net_device *dev,
+ struct ethtool_pauseparam *pause)
+{
+ struct mvpp2_port *port = netdev_priv(dev);
+
+ if (!port->phylink)
+ return -ENOTSUPP;
+
+ return phylink_ethtool_set_pauseparam(port->phylink, pause);
+}
+
+static int mvpp2_ethtool_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
+{
+ struct mvpp2_port *port = netdev_priv(dev);
+
+ if (!port->phylink)
+ return -ENOTSUPP;
+
+ return phylink_ethtool_ksettings_get(port->phylink, cmd);
+}
+
+static int mvpp2_ethtool_set_link_ksettings(struct net_device *dev,
+ const struct ethtool_link_ksettings *cmd)
+{
+ struct mvpp2_port *port = netdev_priv(dev);
+
+ if (!port->phylink)
+ return -ENOTSUPP;
+
+ return phylink_ethtool_ksettings_set(port->phylink, cmd);
+}
+
/* Device ops */

static const struct net_device_ops mvpp2_netdev_ops = {
@@ -7885,7 +7729,7 @@ static const struct net_device_ops mvpp2_netdev_ops = {
};

static const struct ethtool_ops mvpp2_eth_tool_ops = {
- .nway_reset = phy_ethtool_nway_reset,
+ .nway_reset = mvpp2_ethtool_nway_reset,
.get_link = ethtool_op_get_link,
.set_coalesce = mvpp2_ethtool_set_coalesce,
.get_coalesce = mvpp2_ethtool_get_coalesce,
@@ -7895,8 +7739,10 @@ static const struct ethtool_ops mvpp2_eth_tool_ops = {
.get_strings = mvpp2_ethtool_get_strings,
.get_ethtool_stats = mvpp2_ethtool_get_stats,
.get_sset_count = mvpp2_ethtool_get_sset_count,
- .get_link_ksettings = phy_ethtool_get_link_ksettings,
- .set_link_ksettings = phy_ethtool_set_link_ksettings,
+ .get_pauseparam = mvpp2_ethtool_get_pause_param,
+ .set_pauseparam = mvpp2_ethtool_set_pause_param,
+ .get_link_ksettings = mvpp2_ethtool_get_link_ksettings,
+ .set_link_ksettings = mvpp2_ethtool_set_link_ksettings,
};

/* Used for PPv2.1, or PPv2.2 with the old Device Tree binding that
@@ -8198,18 +8044,323 @@ static void mvpp2_port_copy_mac_addr(struct net_device *dev, struct mvpp2 *priv,
eth_hw_addr_random(dev);
}

+static void mvpp2_phylink_validate(struct net_device *dev,
+ unsigned long *supported,
+ struct phylink_link_state *state)
+{
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+
+ phylink_set(mask, Autoneg);
+ phylink_set_port_modes(mask);
+ phylink_set(mask, Pause);
+ phylink_set(mask, Asym_Pause);
+
+ phylink_set(mask, 10baseT_Half);
+ phylink_set(mask, 10baseT_Full);
+ phylink_set(mask, 100baseT_Half);
+ phylink_set(mask, 100baseT_Full);
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseX_Full);
+ phylink_set(mask, 10000baseT_Full);
+
+ if (state->interface == PHY_INTERFACE_MODE_10GKR) {
+ phylink_set(mask, 10000baseCR_Full);
+ phylink_set(mask, 10000baseSR_Full);
+ phylink_set(mask, 10000baseLR_Full);
+ phylink_set(mask, 10000baseLRM_Full);
+ phylink_set(mask, 10000baseER_Full);
+ phylink_set(mask, 10000baseKR_Full);
+ }
+
+ bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
+ bitmap_and(state->advertising, state->advertising, mask,
+ __ETHTOOL_LINK_MODE_MASK_NBITS);
+}
+
+static void mvpp22_xlg_link_state(struct mvpp2_port *port,
+ struct phylink_link_state *state)
+{
+ u32 val;
+
+ state->speed = SPEED_10000;
+ state->duplex = 1;
+ state->an_complete = 1;
+
+ val = readl(port->base + MVPP22_XLG_STATUS);
+ state->link = !!(val & MVPP22_XLG_STATUS_LINK_UP);
+
+ state->pause = 0;
+ val = readl(port->base + MVPP22_XLG_CTRL0_REG);
+ if (val & MVPP22_XLG_CTRL0_TX_FLOW_CTRL_EN)
+ state->pause |= MLO_PAUSE_TX;
+ if (val & MVPP22_XLG_CTRL0_RX_FLOW_CTRL_EN)
+ state->pause |= MLO_PAUSE_RX;
+}
+
+static void mvpp2_gmac_link_state(struct mvpp2_port *port,
+ struct phylink_link_state *state)
+{
+ u32 val;
+
+ val = readl(port->base + MVPP2_GMAC_STATUS0);
+
+ state->an_complete = !!(val & MVPP2_GMAC_STATUS0_AN_COMPLETE);
+ state->link = !!(val & MVPP2_GMAC_STATUS0_LINK_UP);
+ state->duplex = !!(val & MVPP2_GMAC_STATUS0_FULL_DUPLEX);
+
+ if (val & MVPP2_GMAC_STATUS0_GMII_SPEED)
+ state->speed = SPEED_1000;
+ else if (val & MVPP2_GMAC_STATUS0_MII_SPEED)
+ state->speed = SPEED_100;
+ else
+ state->speed = SPEED_10;
+
+ state->pause = 0;
+ if (val & MVPP2_GMAC_STATUS0_RX_PAUSE)
+ state->pause |= MLO_PAUSE_RX;
+ if (val & MVPP2_GMAC_STATUS0_TX_PAUSE)
+ state->pause |= MLO_PAUSE_TX;
+}
+
+static int mvpp2_phylink_mac_link_state(struct net_device *dev,
+ struct phylink_link_state *state)
+{
+ struct mvpp2_port *port = netdev_priv(dev);
+
+ if (port->priv->hw_version == MVPP22 && port->gop_id == 0) {
+ u32 mode = readl(port->base + MVPP22_XLG_CTRL3_REG);
+ mode &= MVPP22_XLG_CTRL3_MACMODESELECT_MASK;
+
+ if (mode == MVPP22_XLG_CTRL3_MACMODESELECT_10G) {
+ mvpp22_xlg_link_state(port, state);
+ return 1;
+ }
+ }
+
+ mvpp2_gmac_link_state(port, state);
+ return 1;
+}
+
+static void mvpp2_mac_an_restart(struct net_device *dev)
+{
+ struct mvpp2_port *port = netdev_priv(dev);
+ u32 val;
+
+ if (port->phy_interface != PHY_INTERFACE_MODE_SGMII)
+ return;
+
+ val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ /* The RESTART_AN bit is cleared by the h/w after restarting the AN
+ * process.
+ */
+ val |= MVPP2_GMAC_IN_BAND_RESTART_AN | MVPP2_GMAC_IN_BAND_AUTONEG;
+ writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+}
+
+static void mvpp2_xlg_config(struct mvpp2_port *port, unsigned int mode,
+ const struct phylink_link_state *state)
+{
+ u32 ctrl0, ctrl4;
+
+ ctrl0 = readl(port->base + MVPP22_XLG_CTRL0_REG);
+ ctrl4 = readl(port->base + MVPP22_XLG_CTRL4_REG);
+
+ if (state->pause & MLO_PAUSE_TX)
+ ctrl0 |= MVPP22_XLG_CTRL0_TX_FLOW_CTRL_EN;
+ if (state->pause & MLO_PAUSE_RX)
+ ctrl0 |= MVPP22_XLG_CTRL0_RX_FLOW_CTRL_EN;
+
+ ctrl4 &= ~MVPP22_XLG_CTRL4_MACMODSELECT_GMAC;
+ ctrl4 |= MVPP22_XLG_CTRL4_FWD_FC | MVPP22_XLG_CTRL4_FWD_PFC;
+
+ writel(ctrl0, port->base + MVPP22_XLG_CTRL0_REG);
+ writel(ctrl4, port->base + MVPP22_XLG_CTRL4_REG);
+}
+
+static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
+ const struct phylink_link_state *state)
+{
+ u32 an, ctrl0, ctrl2, ctrl4;
+
+ an = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ ctrl0 = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
+ ctrl2 = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
+ ctrl4 = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
+
+ /* Force link down */
+ an &= ~MVPP2_GMAC_FORCE_LINK_PASS;
+ an |= MVPP2_GMAC_FORCE_LINK_DOWN;
+ writel(an, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+
+ /* Set the GMAC in a reset state */
+ ctrl2 |= MVPP2_GMAC_PORT_RESET_MASK;
+ writel(ctrl2, port->base + MVPP2_GMAC_CTRL_2_REG);
+
+ an &= ~(MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_FC_ADV_EN |
+ MVPP2_GMAC_FC_ADV_ASM_EN | MVPP2_GMAC_FLOW_CTRL_AUTONEG |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX | MVPP2_GMAC_AN_DUPLEX_EN |
+ MVPP2_GMAC_FORCE_LINK_DOWN);
+ ctrl0 &= ~MVPP2_GMAC_PORT_TYPE_MASK;
+ ctrl2 &= ~(MVPP2_GMAC_PORT_RESET_MASK | MVPP2_GMAC_PCS_ENABLE_MASK);
+
+ an |= MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_FLOW_CTRL_AUTONEG;
+
+ if (state->duplex)
+ an |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ if (phylink_test(state->advertising, Pause))
+ an |= MVPP2_GMAC_FC_ADV_EN;
+ if (phylink_test(state->advertising, Asym_Pause))
+ an |= MVPP2_GMAC_FC_ADV_ASM_EN;
+
+ if (state->interface == PHY_INTERFACE_MODE_SGMII) {
+ an |= MVPP2_GMAC_IN_BAND_AUTONEG;
+ ctrl2 |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;
+
+ ctrl4 &= ~(MVPP22_CTRL4_EXT_PIN_GMII_SEL |
+ MVPP22_CTRL4_RX_FC_EN | MVPP22_CTRL4_TX_FC_EN);
+ ctrl4 |= MVPP22_CTRL4_SYNC_BYPASS_DIS |
+ MVPP22_CTRL4_DP_CLK_SEL |
+ MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
+
+ if (state->pause & MLO_PAUSE_TX)
+ ctrl4 |= MVPP22_CTRL4_TX_FC_EN;
+ if (state->pause & MLO_PAUSE_RX)
+ ctrl4 |= MVPP22_CTRL4_RX_FC_EN;
+ } else if (phy_interface_mode_is_rgmii(state->interface)) {
+ an |= MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS;
+
+ if (state->speed == SPEED_1000)
+ an |= MVPP2_GMAC_STATUS0_GMII_SPEED;
+ else if (state->speed == SPEED_100)
+ an |= MVPP2_GMAC_STATUS0_MII_SPEED;
+
+ ctrl4 &= ~MVPP22_CTRL4_DP_CLK_SEL;
+ ctrl4 |= MVPP22_CTRL4_EXT_PIN_GMII_SEL |
+ MVPP22_CTRL4_SYNC_BYPASS_DIS |
+ MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
+ }
+
+ writel(ctrl0, port->base + MVPP2_GMAC_CTRL_0_REG);
+ writel(ctrl2, port->base + MVPP2_GMAC_CTRL_2_REG);
+ writel(ctrl4, port->base + MVPP22_GMAC_CTRL_4_REG);
+ writel(an, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+}
+
+static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
+ const struct phylink_link_state *state)
+{
+ struct mvpp2_port *port = netdev_priv(dev);
+
+ /* Check for invalid configuration */
+ if (state->interface == PHY_INTERFACE_MODE_10GKR && port->gop_id != 0) {
+ netdev_err(dev, "Invalid mode on %s\n", dev->name);
+ return;
+ }
+
+ /* Make sure the port is disabled when reconfiguring the mode */
+ netif_carrier_off(port->dev);
+ mvpp2_port_disable(port);
+
+ if (port->priv->hw_version == MVPP22 &&
+ port->phy_interface != state->interface) {
+ port->phy_interface = state->interface;
+
+ /* Reconfigure the serdes lanes */
+ phy_power_off(port->comphy);
+ mvpp22_mode_reconfigure(port);
+ }
+
+ /* mac (re)configuration */
+ if (state->interface == PHY_INTERFACE_MODE_10GKR)
+ mvpp2_xlg_config(port, mode, state);
+ else if (phy_interface_mode_is_rgmii(state->interface) ||
+ state->interface == PHY_INTERFACE_MODE_SGMII)
+ mvpp2_gmac_config(port, mode, state);
+
+ if (port->priv->hw_version == MVPP21 && port->flags & MVPP2_F_LOOPBACK)
+ mvpp2_port_loopback_set(port, state);
+
+ /* If the port already was up, make sure it's still in the same state */
+ if (state->link || !port->has_phy) {
+ mvpp2_port_enable(port);
+
+ mvpp2_egress_enable(port);
+ mvpp2_ingress_enable(port);
+ netif_carrier_on(dev);
+ netif_tx_wake_all_queues(dev);
+ }
+}
+
+static void mvpp2_mac_link_up(struct net_device *dev, unsigned int mode,
+ struct phy_device *phy)
+{
+ struct mvpp2_port *port = netdev_priv(dev);
+ u32 val;
+
+ if (!phylink_autoneg_inband(mode) &&
+ port->phy_interface != PHY_INTERFACE_MODE_10GKR) {
+ val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ val &= ~MVPP2_GMAC_FORCE_LINK_DOWN;
+ val |= MVPP2_GMAC_FORCE_LINK_PASS;
+ writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ }
+
+ mvpp2_port_enable(port);
+
+ mvpp2_egress_enable(port);
+ mvpp2_ingress_enable(port);
+ netif_tx_wake_all_queues(dev);
+}
+
+static void mvpp2_mac_link_down(struct net_device *dev, unsigned int mode)
+{
+ struct mvpp2_port *port = netdev_priv(dev);
+ u32 val;
+
+ if (!phylink_autoneg_inband(mode) &&
+ port->phy_interface != PHY_INTERFACE_MODE_10GKR) {
+ val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ val &= ~MVPP2_GMAC_FORCE_LINK_PASS;
+ val |= MVPP2_GMAC_FORCE_LINK_DOWN;
+ writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ }
+
+ netif_tx_stop_all_queues(dev);
+ mvpp2_egress_disable(port);
+ mvpp2_ingress_disable(port);
+
+ /* When using link interrupts to notify phylink of a MAC state change,
+ * we do not want the port to be disabled (we want to receive further
+ * interrupts, to be notified when the port will have a link later).
+ */
+ if (!port->has_phy)
+ return;
+
+ mvpp2_port_disable(port);
+}
+
+static const struct phylink_mac_ops mvpp2_phylink_ops = {
+ .validate = mvpp2_phylink_validate,
+ .mac_link_state = mvpp2_phylink_mac_link_state,
+ .mac_an_restart = mvpp2_mac_an_restart,
+ .mac_config = mvpp2_mac_config,
+ .mac_link_up = mvpp2_mac_link_up,
+ .mac_link_down = mvpp2_mac_link_down,
+};
+
/* Ports initialization */
static int mvpp2_port_probe(struct platform_device *pdev,
struct fwnode_handle *port_fwnode,
struct mvpp2 *priv)
{
- struct device_node *phy_node;
struct phy *comphy = NULL;
struct mvpp2_port *port;
struct mvpp2_port_pcpu *port_pcpu;
struct device_node *port_node = to_of_node(port_fwnode);
struct net_device *dev;
struct resource *res;
+ struct phylink *phylink;
char *mac_from = "";
unsigned int ntxqs, nrxqs;
bool has_tx_irqs;
@@ -8238,11 +8389,6 @@ static int mvpp2_port_probe(struct platform_device *pdev,
if (!dev)
return -ENOMEM;

- if (port_node)
- phy_node = of_parse_phandle(port_node, "phy", 0);
- else
- phy_node = NULL;
-
phy_mode = fwnode_get_phy_mode(port_fwnode);
if (phy_mode < 0) {
dev_err(&pdev->dev, "incorrect phy mode\n");
@@ -8275,6 +8421,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
port = netdev_priv(dev);
port->dev = dev;
port->fwnode = port_fwnode;
+ port->has_phy = !!of_find_property(port_node, "phy", NULL);
port->ntxqs = ntxqs;
port->nrxqs = nrxqs;
port->priv = priv;
@@ -8305,7 +8452,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
else
port->first_rxq = port->id * priv->max_port_rxqs;

- port->phy_node = phy_node;
+ port->of_node = port_node;
port->phy_interface = phy_mode;
port->comphy = comphy;

@@ -8366,9 +8513,6 @@ static int mvpp2_port_probe(struct platform_device *pdev,

mvpp2_port_periodic_xon_disable(port);

- if (priv->hw_version == MVPP21)
- mvpp2_port_fc_adv_enable(port);
-
mvpp2_port_reset(port);

port->pcpu = alloc_percpu(struct mvpp2_port_pcpu);
@@ -8412,10 +8556,23 @@ static int mvpp2_port_probe(struct platform_device *pdev,
/* 9704 == 9728 - 20 and rounding to 8 */
dev->max_mtu = MVPP2_BM_JUMBO_PKT_SIZE;

+ /* Phylink isn't used w/ ACPI as of now */
+ if (port_node) {
+ phylink = phylink_create(dev, port_fwnode, phy_mode,
+ &mvpp2_phylink_ops);
+ if (IS_ERR(phylink)) {
+ err = PTR_ERR(phylink);
+ goto err_free_port_pcpu;
+ }
+ port->phylink = phylink;
+ } else {
+ port->phylink = NULL;
+ }
+
err = register_netdev(dev);
if (err < 0) {
dev_err(&pdev->dev, "failed to register netdev\n");
- goto err_free_port_pcpu;
+ goto err_phylink;
}
netdev_info(dev, "Using %s mac address %pM\n", mac_from, dev->dev_addr);

@@ -8423,6 +8580,9 @@ static int mvpp2_port_probe(struct platform_device *pdev,

return 0;

+err_phylink:
+ if (port->phylink)
+ phylink_destroy(port->phylink);
err_free_port_pcpu:
free_percpu(port->pcpu);
err_free_txq_pcpu:
@@ -8436,7 +8596,6 @@ static int mvpp2_port_probe(struct platform_device *pdev,
err_deinit_qvecs:
mvpp2_queue_vectors_deinit(port);
err_free_netdev:
- of_node_put(phy_node);
free_netdev(dev);
return err;
}
@@ -8447,7 +8606,8 @@ static void mvpp2_port_remove(struct mvpp2_port *port)
int i;

unregister_netdev(port->dev);
- of_node_put(port->phy_node);
+ if (port->phylink)
+ phylink_destroy(port->phylink);
free_percpu(port->pcpu);
free_percpu(port->stats);
for (i = 0; i < port->ntxqs; i++)
--
2.14.3


2018-03-16 10:38:42

by Antoine Tenart

[permalink] [raw]
Subject: [PATCH net-next 10/10] arm64: dts: marvell: mcbin: enable the fourth network interface

This patch enables the fourth network interface on the Marvell
Macchiatobin. It is configured in the 2500Base-X PHY mode.

Signed-off-by: Antoine Tenart <[email protected]>
---
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
index 626e9d0462c3..1ce31bfe6197 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -66,6 +66,7 @@
ethernet0 = &cp0_eth0;
ethernet1 = &cp1_eth0;
ethernet2 = &cp1_eth1;
+ ethernet3 = &cp1_eth2;
};

/* Regulator labels correspond with schematics */
@@ -285,6 +286,16 @@
phys = <&cp1_comphy0 1>;
};

+&cp1_eth2 {
+ /* CPS Lane 5 */
+ status = "okay";
+ /* Network PHY */
+ phy-mode = "2500base-x";
+ managed = "in-band-status";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cp1_comphy5 2>;
+};
+
&cp1_pinctrl {
cp1_spi1_pins: spi1-pins {
marvell,pins = "mpp12", "mpp13", "mpp14", "mpp15", "mpp16";
--
2.14.3


2018-03-16 10:39:00

by Antoine Tenart

[permalink] [raw]
Subject: [PATCH net-next 06/10] net: mvpp2: 1000baseX support

This patch adds the 1000Base-X PHY mode support in the Marvell PPv2
driver. 1000Base-X is quite close the SGMII and uses nearly the same
code path.

Signed-off-by: Antoine Tenart <[email protected]>
---
drivers/net/ethernet/marvell/mvpp2.c | 74 +++++++++++++++++++++++++-----------
1 file changed, 52 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 8e8e7afcd437..f6c35b688af4 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4896,6 +4896,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
mvpp22_gop_init_rgmii(port);
break;
case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4933,7 +4934,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
u32 val;

if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4963,7 +4965,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
}

if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4975,7 +4978,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
u32 val;

if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -5000,6 +5004,7 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)

switch (port->phy_interface) {
case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -5079,7 +5084,8 @@ static void mvpp2_port_loopback_set(struct mvpp2_port *port,
else
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;

- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
val |= MVPP2_GMAC_PCS_LB_EN_MASK;
else
val &= ~MVPP2_GMAC_PCS_LB_EN_MASK;
@@ -6288,7 +6294,8 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
link = true;
}
} else if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_STAT);
if (val & MVPP22_GMAC_INT_STAT_LINK) {
event = true;
@@ -8055,21 +8062,25 @@ static void mvpp2_phylink_validate(struct net_device *dev,
phylink_set(mask, Pause);
phylink_set(mask, Asym_Pause);

- phylink_set(mask, 10baseT_Half);
- phylink_set(mask, 10baseT_Full);
- phylink_set(mask, 100baseT_Half);
- phylink_set(mask, 100baseT_Full);
- phylink_set(mask, 1000baseT_Full);
- phylink_set(mask, 1000baseX_Full);
- phylink_set(mask, 10000baseT_Full);
-
- if (state->interface == PHY_INTERFACE_MODE_10GKR) {
+ switch (state->interface) {
+ case PHY_INTERFACE_MODE_10GKR:
phylink_set(mask, 10000baseCR_Full);
phylink_set(mask, 10000baseSR_Full);
phylink_set(mask, 10000baseLR_Full);
phylink_set(mask, 10000baseLRM_Full);
phylink_set(mask, 10000baseER_Full);
phylink_set(mask, 10000baseKR_Full);
+ /* Fall-through */
+ default:
+ phylink_set(mask, 10baseT_Half);
+ phylink_set(mask, 10baseT_Full);
+ phylink_set(mask, 100baseT_Half);
+ phylink_set(mask, 100baseT_Full);
+ phylink_set(mask, 10000baseT_Full);
+ /* Fall-through */
+ case PHY_INTERFACE_MODE_1000BASEX:
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseX_Full);
}

bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
@@ -8108,12 +8119,18 @@ static void mvpp2_gmac_link_state(struct mvpp2_port *port,
state->link = !!(val & MVPP2_GMAC_STATUS0_LINK_UP);
state->duplex = !!(val & MVPP2_GMAC_STATUS0_FULL_DUPLEX);

- if (val & MVPP2_GMAC_STATUS0_GMII_SPEED)
+ switch (port->phy_interface) {
+ case PHY_INTERFACE_MODE_1000BASEX:
state->speed = SPEED_1000;
- else if (val & MVPP2_GMAC_STATUS0_MII_SPEED)
- state->speed = SPEED_100;
- else
- state->speed = SPEED_10;
+ break;
+ default:
+ if (val & MVPP2_GMAC_STATUS0_GMII_SPEED)
+ state->speed = SPEED_1000;
+ else if (val & MVPP2_GMAC_STATUS0_MII_SPEED)
+ state->speed = SPEED_100;
+ else
+ state->speed = SPEED_10;
+ }

state->pause = 0;
if (val & MVPP2_GMAC_STATUS0_RX_PAUSE)
@@ -8204,7 +8221,18 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
ctrl0 &= ~MVPP2_GMAC_PORT_TYPE_MASK;
ctrl2 &= ~(MVPP2_GMAC_PORT_RESET_MASK | MVPP2_GMAC_PCS_ENABLE_MASK);

- an |= MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_FLOW_CTRL_AUTONEG;
+ if (state->interface == PHY_INTERFACE_MODE_1000BASEX) {
+ /* 1000BaseX port cannot negotiate speed nor can it negotiate
+ * duplex: they are always operating with a fixed speed of
+ * 1000Mbps in full duplex, so force 1000 speed and full duplex
+ * here.
+ */
+ ctrl0 |= MVPP2_GMAC_PORT_TYPE_MASK;
+ an |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ } else {
+ an |= MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_FLOW_CTRL_AUTONEG;
+ }

if (state->duplex)
an |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
@@ -8213,7 +8241,8 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
if (phylink_test(state->advertising, Asym_Pause))
an |= MVPP2_GMAC_FC_ADV_ASM_EN;

- if (state->interface == PHY_INTERFACE_MODE_SGMII) {
+ if (state->interface == PHY_INTERFACE_MODE_SGMII ||
+ state->interface == PHY_INTERFACE_MODE_1000BASEX) {
an |= MVPP2_GMAC_IN_BAND_AUTONEG;
ctrl2 |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;

@@ -8275,7 +8304,8 @@ static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
if (state->interface == PHY_INTERFACE_MODE_10GKR)
mvpp2_xlg_config(port, mode, state);
else if (phy_interface_mode_is_rgmii(state->interface) ||
- state->interface == PHY_INTERFACE_MODE_SGMII)
+ state->interface == PHY_INTERFACE_MODE_SGMII ||
+ state->interface == PHY_INTERFACE_MODE_1000BASEX)
mvpp2_gmac_config(port, mode, state);

if (port->priv->hw_version == MVPP21 && port->flags & MVPP2_F_LOOPBACK)
--
2.14.3


2018-03-16 10:39:20

by Antoine Tenart

[permalink] [raw]
Subject: [PATCH net-next 07/10] net: mvpp2: 2500baseX support

This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
nearly the same code path.

Signed-off-by: Antoine Tenart <[email protected]>
---
drivers/net/ethernet/marvell/mvpp2.c | 51 +++++++++++++++++++++++++++---------
1 file changed, 39 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index f6c35b688af4..c4de3422d688 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4897,6 +4897,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
break;
case PHY_INTERFACE_MODE_SGMII:
case PHY_INTERFACE_MODE_1000BASEX:
+ case PHY_INTERFACE_MODE_2500BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4935,7 +4936,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)

if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4966,7 +4968,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)

if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4979,7 +4982,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)

if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4994,6 +4998,16 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
mvpp22_gop_unmask_irq(port);
}

+/* Sets the PHY mode of the COMPHY (which configures the serdes lanes).
+ *
+ * The PHY mode used by the PPv2 driver comes from the network subsystem, while
+ * the one given to the COMPHY comes from the generic PHY subsystem. Hence they
+ * differ.
+ *
+ * The COMPHY configures the serdes lanes regardless of the actual use of the
+ * lanes by the physical layer. This is why configurations like
+ * "PPv2 (2500BaseX) - COMPHY (2500SGMII)" are valid.
+ */
static int mvpp22_comphy_init(struct mvpp2_port *port)
{
enum phy_mode mode;
@@ -5007,6 +5021,9 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
+ case PHY_INTERFACE_MODE_2500BASEX:
+ mode = PHY_MODE_2500SGMII;
+ break;
case PHY_INTERFACE_MODE_10GKR:
mode = PHY_MODE_10GKR;
break;
@@ -5085,7 +5102,8 @@ static void mvpp2_port_loopback_set(struct mvpp2_port *port,
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;

if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PCS_LB_EN_MASK;
else
val &= ~MVPP2_GMAC_PCS_LB_EN_MASK;
@@ -6295,7 +6313,8 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
}
} else if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_STAT);
if (val & MVPP22_GMAC_INT_STAT_LINK) {
event = true;
@@ -8079,8 +8098,10 @@ static void mvpp2_phylink_validate(struct net_device *dev,
phylink_set(mask, 10000baseT_Full);
/* Fall-through */
case PHY_INTERFACE_MODE_1000BASEX:
+ case PHY_INTERFACE_MODE_2500BASEX:
phylink_set(mask, 1000baseT_Full);
phylink_set(mask, 1000baseX_Full);
+ phylink_set(mask, 2500baseX_Full);
}

bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
@@ -8123,6 +8144,9 @@ static void mvpp2_gmac_link_state(struct mvpp2_port *port,
case PHY_INTERFACE_MODE_1000BASEX:
state->speed = SPEED_1000;
break;
+ case PHY_INTERFACE_MODE_2500BASEX:
+ state->speed = SPEED_2500;
+ break;
default:
if (val & MVPP2_GMAC_STATUS0_GMII_SPEED)
state->speed = SPEED_1000;
@@ -8221,11 +8245,12 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
ctrl0 &= ~MVPP2_GMAC_PORT_TYPE_MASK;
ctrl2 &= ~(MVPP2_GMAC_PORT_RESET_MASK | MVPP2_GMAC_PCS_ENABLE_MASK);

- if (state->interface == PHY_INTERFACE_MODE_1000BASEX) {
- /* 1000BaseX port cannot negotiate speed nor can it negotiate
- * duplex: they are always operating with a fixed speed of
- * 1000Mbps in full duplex, so force 1000 speed and full duplex
- * here.
+ if (state->interface == PHY_INTERFACE_MODE_1000BASEX ||
+ state->interface == PHY_INTERFACE_MODE_2500BASEX) {
+ /* 1000BaseX and 2500BaseX ports cannot negotiate speed nor can
+ * they negotiate duplex: they are always operating with a fixed
+ * speed of 1000/2500Mbps in full duplex, so force 1000/2500
+ * speed and full duplex here.
*/
ctrl0 |= MVPP2_GMAC_PORT_TYPE_MASK;
an |= MVPP2_GMAC_CONFIG_GMII_SPEED |
@@ -8242,7 +8267,8 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
an |= MVPP2_GMAC_FC_ADV_ASM_EN;

if (state->interface == PHY_INTERFACE_MODE_SGMII ||
- state->interface == PHY_INTERFACE_MODE_1000BASEX) {
+ state->interface == PHY_INTERFACE_MODE_1000BASEX ||
+ state->interface == PHY_INTERFACE_MODE_2500BASEX) {
an |= MVPP2_GMAC_IN_BAND_AUTONEG;
ctrl2 |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;

@@ -8305,7 +8331,8 @@ static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
mvpp2_xlg_config(port, mode, state);
else if (phy_interface_mode_is_rgmii(state->interface) ||
state->interface == PHY_INTERFACE_MODE_SGMII ||
- state->interface == PHY_INTERFACE_MODE_1000BASEX)
+ state->interface == PHY_INTERFACE_MODE_1000BASEX ||
+ state->interface == PHY_INTERFACE_MODE_2500BASEX)
mvpp2_gmac_config(port, mode, state);

if (port->priv->hw_version == MVPP21 && port->flags & MVPP2_F_LOOPBACK)
--
2.14.3


2018-03-16 10:40:13

by Antoine Tenart

[permalink] [raw]
Subject: [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode

This patch allow the CP100 comphy to configure some lanes in the
2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
same code path.

Signed-off-by: Antoine Tenart <[email protected]>
---
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index a0d522154cdf..4ef429250d7b 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -135,19 +135,25 @@ struct mvebu_comhy_conf {
static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
/* lane 0 */
MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(0, 1, PHY_MODE_2500SGMII, 0x1),
/* lane 1 */
MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(1, 2, PHY_MODE_2500SGMII, 0x1),
/* lane 2 */
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(2, 0, PHY_MODE_2500SGMII, 0x1),
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
/* lane 3 */
MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
+ MVEBU_COMPHY_CONF(3, 1, PHY_MODE_2500SGMII, 0x2),
/* lane 4 */
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
+ MVEBU_COMPHY_CONF(4, 0, PHY_MODE_2500SGMII, 0x2),
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
/* lane 5 */
MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(5, 2, PHY_MODE_2500SGMII, 0x1),
};

struct mvebu_comphy_priv {
@@ -206,6 +212,10 @@ static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
if (mode == PHY_MODE_10GKR)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xe) |
MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xe);
+ else if (mode == PHY_MODE_2500SGMII)
+ val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x8) |
+ MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x8) |
+ MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
else if (mode == PHY_MODE_SGMII)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x6) |
MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x6) |
@@ -296,13 +306,13 @@ static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane,
return 0;
}

-static int mvebu_comphy_set_mode_sgmii(struct phy *phy)
+static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
{
struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
struct mvebu_comphy_priv *priv = lane->priv;
u32 val;

- mvebu_comphy_ethernet_init_reset(lane, PHY_MODE_SGMII);
+ mvebu_comphy_ethernet_init_reset(lane, mode);

val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
val &= ~MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
@@ -487,7 +497,8 @@ static int mvebu_comphy_power_on(struct phy *phy)

switch (lane->mode) {
case PHY_MODE_SGMII:
- ret = mvebu_comphy_set_mode_sgmii(phy);
+ case PHY_MODE_2500SGMII:
+ ret = mvebu_comphy_set_mode_sgmii(phy, lane->mode);
break;
case PHY_MODE_10GKR:
ret = mvebu_comphy_set_mode_10gkr(phy);
--
2.14.3


2018-03-16 10:40:56

by Antoine Tenart

[permalink] [raw]
Subject: [PATCH net-next 04/10] phy: add 2.5G SGMII mode to the phy_mode enum

This patch adds one more generic PHY mode to the phy_mode enum, to allow
configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
callback.

Signed-off-by: Antoine Tenart <[email protected]>
---
include/linux/phy/phy.h | 1 +
1 file changed, 1 insertion(+)

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 4f8423a948d5..5a80e9de3686 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -28,6 +28,7 @@ enum phy_mode {
PHY_MODE_USB_DEVICE,
PHY_MODE_USB_OTG,
PHY_MODE_SGMII,
+ PHY_MODE_2500SGMII,
PHY_MODE_10GKR,
PHY_MODE_UFS_HS_A,
PHY_MODE_UFS_HS_B,
--
2.14.3


2018-03-16 10:42:15

by Antoine Tenart

[permalink] [raw]
Subject: [PATCH net-next 01/10] net: mvpp2: align the ethtool ops definition

Cosmetic patch to align the ethtool functions to ops definitions. This
patch does not change in any way the driver's behaviour.

Signed-off-by: Antoine Tenart <[email protected]>
---
drivers/net/ethernet/marvell/mvpp2.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 9bd35f2291d6..430114ad93fc 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -7885,18 +7885,18 @@ static const struct net_device_ops mvpp2_netdev_ops = {
};

static const struct ethtool_ops mvpp2_eth_tool_ops = {
- .nway_reset = phy_ethtool_nway_reset,
- .get_link = ethtool_op_get_link,
- .set_coalesce = mvpp2_ethtool_set_coalesce,
- .get_coalesce = mvpp2_ethtool_get_coalesce,
- .get_drvinfo = mvpp2_ethtool_get_drvinfo,
- .get_ringparam = mvpp2_ethtool_get_ringparam,
- .set_ringparam = mvpp2_ethtool_set_ringparam,
- .get_strings = mvpp2_ethtool_get_strings,
- .get_ethtool_stats = mvpp2_ethtool_get_stats,
- .get_sset_count = mvpp2_ethtool_get_sset_count,
- .get_link_ksettings = phy_ethtool_get_link_ksettings,
- .set_link_ksettings = phy_ethtool_set_link_ksettings,
+ .nway_reset = phy_ethtool_nway_reset,
+ .get_link = ethtool_op_get_link,
+ .set_coalesce = mvpp2_ethtool_set_coalesce,
+ .get_coalesce = mvpp2_ethtool_get_coalesce,
+ .get_drvinfo = mvpp2_ethtool_get_drvinfo,
+ .get_ringparam = mvpp2_ethtool_get_ringparam,
+ .set_ringparam = mvpp2_ethtool_set_ringparam,
+ .get_strings = mvpp2_ethtool_get_strings,
+ .get_ethtool_stats = mvpp2_ethtool_get_stats,
+ .get_sset_count = mvpp2_ethtool_get_sset_count,
+ .get_link_ksettings = phy_ethtool_get_link_ksettings,
+ .set_link_ksettings = phy_ethtool_set_link_ksettings,
};

/* Used for PPv2.1, or PPv2.2 with the old Device Tree binding that
--
2.14.3


2018-03-16 10:42:20

by Antoine Tenart

[permalink] [raw]
Subject: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

The PHY mode 10GKR can use in-band negotiation. This patches allows this
mode to be used with MLO_AN_INBAND in phylink.

Signed-off-by: Antoine Tenart <[email protected]>
---
drivers/net/phy/phylink.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 51a011a349fe..7224b005f0dd 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -768,7 +768,8 @@ int phylink_of_phy_connect(struct phylink *pl, struct device_node *dn,
/* Fixed links and 802.3z are handled without needing a PHY */
if (pl->link_an_mode == MLO_AN_FIXED ||
(pl->link_an_mode == MLO_AN_INBAND &&
- phy_interface_mode_is_8023z(pl->link_interface)))
+ (phy_interface_mode_is_8023z(pl->link_interface) ||
+ pl->link_interface == PHY_INTERFACE_MODE_10GKR)))
return 0;

phy_node = of_parse_phandle(dn, "phy-handle", 0);
--
2.14.3


2018-03-16 15:58:02

by Russell King (Oracle)

[permalink] [raw]
Subject: Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote:
> The PHY mode 10GKR can use in-band negotiation. This patches allows this
> mode to be used with MLO_AN_INBAND in phylink.
>
> Signed-off-by: Antoine Tenart <[email protected]>
> ---
> drivers/net/phy/phylink.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 51a011a349fe..7224b005f0dd 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -768,7 +768,8 @@ int phylink_of_phy_connect(struct phylink *pl, struct device_node *dn,
> /* Fixed links and 802.3z are handled without needing a PHY */
> if (pl->link_an_mode == MLO_AN_FIXED ||
> (pl->link_an_mode == MLO_AN_INBAND &&
> - phy_interface_mode_is_8023z(pl->link_interface)))
> + (phy_interface_mode_is_8023z(pl->link_interface) ||
> + pl->link_interface == PHY_INTERFACE_MODE_10GKR)))

There is no inband negotiation like there is with 802.3z or SGMII,
so this makes no sense.

--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

2018-03-16 16:05:30

by Russell King (Oracle)

[permalink] [raw]
Subject: Re: [PATCH net-next 03/10] net: mvpp2: phylink support

On Fri, Mar 16, 2018 at 11:33:44AM +0100, Antoine Tenart wrote:
> +static void mvpp2_phylink_validate(struct net_device *dev,
> + unsigned long *supported,
> + struct phylink_link_state *state)
> +{
> + __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> +
> + phylink_set(mask, Autoneg);
> + phylink_set_port_modes(mask);
> + phylink_set(mask, Pause);
> + phylink_set(mask, Asym_Pause);
> +
> + phylink_set(mask, 10baseT_Half);
> + phylink_set(mask, 10baseT_Full);
> + phylink_set(mask, 100baseT_Half);
> + phylink_set(mask, 100baseT_Full);
> + phylink_set(mask, 1000baseT_Full);
> + phylink_set(mask, 1000baseX_Full);

AFAICS, the driver (before these patches) does not support 1000baseX
as it always clears the MVPP2_GMAC_PORT_TYPE_MASK bit, so adding this
mode should be part of the patch adding 1000baseX support.

--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

2018-03-18 04:46:52

by Baruch Siach

[permalink] [raw]
Subject: Re: [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode

Hi Antoine,

On Fri, Mar 16, 2018 at 11:33:46AM +0100, Antoine Tenart wrote:
> This patch allow the CP100 comphy to configure some lanes in the

Should be 'CP110'.

> 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
> same code path.
>
> Signed-off-by: Antoine Tenart <[email protected]>

baruch

--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il -

2018-03-19 08:46:49

by Antoine Tenart

[permalink] [raw]
Subject: Re: [PATCH net-next 03/10] net: mvpp2: phylink support

Hi Russell,

On Fri, Mar 16, 2018 at 04:03:22PM +0000, Russell King - ARM Linux wrote:
> On Fri, Mar 16, 2018 at 11:33:44AM +0100, Antoine Tenart wrote:
> > +static void mvpp2_phylink_validate(struct net_device *dev,
> > + unsigned long *supported,
> > + struct phylink_link_state *state)
> > +{
> > + __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> > +
> > + phylink_set(mask, Autoneg);
> > + phylink_set_port_modes(mask);
> > + phylink_set(mask, Pause);
> > + phylink_set(mask, Asym_Pause);
> > +
> > + phylink_set(mask, 10baseT_Half);
> > + phylink_set(mask, 10baseT_Full);
> > + phylink_set(mask, 100baseT_Half);
> > + phylink_set(mask, 100baseT_Full);
> > + phylink_set(mask, 1000baseT_Full);
> > + phylink_set(mask, 1000baseX_Full);
>
> AFAICS, the driver (before these patches) does not support 1000baseX
> as it always clears the MVPP2_GMAC_PORT_TYPE_MASK bit, so adding this
> mode should be part of the patch adding 1000baseX support.

Right, I'll remove 1000baseX_Full from this patch and only add it in the
1000BaseX support patch.

Thanks!
Antoine

--
Antoine T?nart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

2018-03-19 08:55:35

by Antoine Tenart

[permalink] [raw]
Subject: Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

Hi Russell,

On Fri, Mar 16, 2018 at 03:53:07PM +0000, Russell King - ARM Linux wrote:
> On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote:
> > The PHY mode 10GKR can use in-band negotiation. This patches allows this
> > mode to be used with MLO_AN_INBAND in phylink.
> >
> > Signed-off-by: Antoine Tenart <[email protected]>
> > ---
> > drivers/net/phy/phylink.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> > index 51a011a349fe..7224b005f0dd 100644
> > --- a/drivers/net/phy/phylink.c
> > +++ b/drivers/net/phy/phylink.c
> > @@ -768,7 +768,8 @@ int phylink_of_phy_connect(struct phylink *pl, struct device_node *dn,
> > /* Fixed links and 802.3z are handled without needing a PHY */
> > if (pl->link_an_mode == MLO_AN_FIXED ||
> > (pl->link_an_mode == MLO_AN_INBAND &&
> > - phy_interface_mode_is_8023z(pl->link_interface)))
> > + (phy_interface_mode_is_8023z(pl->link_interface) ||
> > + pl->link_interface == PHY_INTERFACE_MODE_10GKR)))
>
> There is no inband negotiation like there is with 802.3z or SGMII,
> so this makes no sense.

Oh, that's what I feared. I read some docs but probably will need more
:)

Anyway, the reason to use in-band negotiation was also to avoid using
fixed-link. It would work but always report the link is up, which for
the user isn't a great experience as we have a way to detect this.

What would you suggest to achieve this in a reasonable way?

Thanks,
Antoine

--
Antoine T?nart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

2018-03-19 09:04:47

by Antoine Tenart

[permalink] [raw]
Subject: Re: [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode

Hi Baruch,

On Sun, Mar 18, 2018 at 06:42:48AM +0200, Baruch Siach wrote:
> On Fri, Mar 16, 2018 at 11:33:46AM +0100, Antoine Tenart wrote:
> > This patch allow the CP100 comphy to configure some lanes in the
>
> Should be 'CP110'.

That's right, I'll update.

Thanks!
Antoine

--
Antoine T?nart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

2018-03-19 10:04:05

by Kishon Vijay Abraham I

[permalink] [raw]
Subject: Re: [PATCH net-next 04/10] phy: add 2.5G SGMII mode to the phy_mode enum



On Friday 16 March 2018 04:03 PM, Antoine Tenart wrote:
> This patch adds one more generic PHY mode to the phy_mode enum, to allow
> configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
> callback.
>
> Signed-off-by: Antoine Tenart <[email protected]>

Acked-by: Kishon Vijay Abraham I <[email protected]>
> ---
> include/linux/phy/phy.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 4f8423a948d5..5a80e9de3686 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -28,6 +28,7 @@ enum phy_mode {
> PHY_MODE_USB_DEVICE,
> PHY_MODE_USB_OTG,
> PHY_MODE_SGMII,
> + PHY_MODE_2500SGMII,
> PHY_MODE_10GKR,
> PHY_MODE_UFS_HS_A,
> PHY_MODE_UFS_HS_B,
>

2018-03-19 11:36:12

by Russell King (Oracle)

[permalink] [raw]
Subject: Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 09:52:52AM +0100, Antoine Tenart wrote:
> Hi Russell,
>
> On Fri, Mar 16, 2018 at 03:53:07PM +0000, Russell King - ARM Linux wrote:
> > On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote:
> > > The PHY mode 10GKR can use in-band negotiation. This patches allows this
> > > mode to be used with MLO_AN_INBAND in phylink.
> > >
> > > Signed-off-by: Antoine Tenart <[email protected]>
> > > ---
> > > drivers/net/phy/phylink.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> > > index 51a011a349fe..7224b005f0dd 100644
> > > --- a/drivers/net/phy/phylink.c
> > > +++ b/drivers/net/phy/phylink.c
> > > @@ -768,7 +768,8 @@ int phylink_of_phy_connect(struct phylink *pl, struct device_node *dn,
> > > /* Fixed links and 802.3z are handled without needing a PHY */
> > > if (pl->link_an_mode == MLO_AN_FIXED ||
> > > (pl->link_an_mode == MLO_AN_INBAND &&
> > > - phy_interface_mode_is_8023z(pl->link_interface)))
> > > + (phy_interface_mode_is_8023z(pl->link_interface) ||
> > > + pl->link_interface == PHY_INTERFACE_MODE_10GKR)))
> >
> > There is no inband negotiation like there is with 802.3z or SGMII,
> > so this makes no sense.
>
> Oh, that's what I feared. I read some docs but probably will need more
> :)
>
> Anyway, the reason to use in-band negotiation was also to avoid using
> fixed-link. It would work but always report the link is up, which for
> the user isn't a great experience as we have a way to detect this.
>
> What would you suggest to achieve this in a reasonable way?

The intention of this test in phylink_of_phy_connect() is to avoid
failing when there is no requirement for a PHY to be present (such as
a fixed link, or an 802.3z link.) However, with 10G PHYs such as the
3310, we need the PHY so we can read the speed from it, and so know
whether to downgrade the MAC to SGMII mode, or having downgraded the
MAC, upgrade it back to 10G mode when the PHY switches to 10G.

I'm guessing that you're wanting this for the DB boards, but I don't
see why. Do they not have PHYs?

--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

2018-03-19 12:54:22

by Antoine Tenart

[permalink] [raw]
Subject: Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

Hi Russell,

On Mon, Mar 19, 2018 at 11:12:05AM +0000, Russell King - ARM Linux wrote:
> On Mon, Mar 19, 2018 at 09:52:52AM +0100, Antoine Tenart wrote:
> >
> > Anyway, the reason to use in-band negotiation was also to avoid using
> > fixed-link. It would work but always report the link is up, which for
> > the user isn't a great experience as we have a way to detect this.
> >
> > What would you suggest to achieve this in a reasonable way?
>
> The intention of this test in phylink_of_phy_connect() is to avoid
> failing when there is no requirement for a PHY to be present (such as
> a fixed link, or an 802.3z link.) However, with 10G PHYs such as the
> 3310, we need the PHY so we can read the speed from it, and so know
> whether to downgrade the MAC to SGMII mode, or having downgraded the
> MAC, upgrade it back to 10G mode when the PHY switches to 10G.
>
> I'm guessing that you're wanting this for the DB boards, but I don't
> see why. Do they not have PHYs?

You guessed right, that's exactly my use case. The DB boards (7k and 8k)
have 10G interfaces without PHYs. I could describe them as fixed-link
(it works), but it would be better not to require a PHY in
phylink_of_phy_connect() for such interfaces.

That's why I used in-band AN, which is wrong, but we still probably
need to add a check to allow such setups. I'm all ears for suggestions
as I do not have the full picture of all the supported modes and their
requirements.

Thanks!
Antoine

--
Antoine T?nart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

2018-03-19 13:04:55

by Yan Markman

[permalink] [raw]
Subject: RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

The DTS-patch for this board (in "old" format) is attached


Yan Markman
Tel. 05-44732819


-----Original Message-----
From: Stefan Chulski
Sent: Monday, March 19, 2018 2:58 PM
To: Russell King - ARM Linux <[email protected]>; Antoine Tenart <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Nadav Haklai <[email protected]>; Yan Markman <[email protected]>; [email protected]; [email protected]
Subject: RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

> > > There is no inband negotiation like there is with 802.3z or SGMII,
> > > so this makes no sense.
> >
> > Oh, that's what I feared. I read some docs but probably will need
> > more
> > :)
> >
> > Anyway, the reason to use in-band negotiation was also to avoid
> > using fixed-link. It would work but always report the link is up,
> > which for the user isn't a great experience as we have a way to detect this.
> >
> > What would you suggest to achieve this in a reasonable way?
>
> The intention of this test in phylink_of_phy_connect() is to avoid
> failing when there is no requirement for a PHY to be present (such as
> a fixed link, or an 802.3z link.) However, with 10G PHYs such as the
> 3310, we need the PHY so we can read the speed from it, and so know
> whether to downgrade the MAC to SGMII mode, or having downgraded the
> MAC, upgrade it back to 10G mode when the PHY switches to 10G.
>
> I'm guessing that you're wanting this for the DB boards, but I don't see why.
> Do they not have PHYs?

New Solid Run board MACCHIATObin Single Shot doesn't has 3310 PHY either, like DB boards.
https://www.cnx-software.com/2017/12/20/solidrun-macchiatobin-single-shot-networking-board-launched-for-269-and-up/

Stefan,
Best Regards.


Attachments:
0001-arm64-dts-marvell-add-new-mcbin-single-shot-board.patch (8.96 kB)
0001-arm64-dts-marvell-add-new-mcbin-single-shot-board.patch

2018-03-19 13:08:07

by Russell King (Oracle)

[permalink] [raw]
Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 01:01:07PM +0000, Yan Markman wrote:
> The DTS-patch for this board (in "old" format) is attached
>
>
> Yan Markman
> Tel. 05-44732819
>
>
> -----Original Message-----
> From: Stefan Chulski
> Sent: Monday, March 19, 2018 2:58 PM
> To: Russell King - ARM Linux <[email protected]>; Antoine Tenart <[email protected]>
> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Nadav Haklai <[email protected]>; Yan Markman <[email protected]>; [email protected]; [email protected]
> Subject: RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
>
> > > > There is no inband negotiation like there is with 802.3z or SGMII,
> > > > so this makes no sense.
> > >
> > > Oh, that's what I feared. I read some docs but probably will need
> > > more
> > > :)
> > >
> > > Anyway, the reason to use in-band negotiation was also to avoid
> > > using fixed-link. It would work but always report the link is up,
> > > which for the user isn't a great experience as we have a way to detect this.
> > >
> > > What would you suggest to achieve this in a reasonable way?
> >
> > The intention of this test in phylink_of_phy_connect() is to avoid
> > failing when there is no requirement for a PHY to be present (such as
> > a fixed link, or an 802.3z link.) However, with 10G PHYs such as the
> > 3310, we need the PHY so we can read the speed from it, and so know
> > whether to downgrade the MAC to SGMII mode, or having downgraded the
> > MAC, upgrade it back to 10G mode when the PHY switches to 10G.
> >
> > I'm guessing that you're wanting this for the DB boards, but I don't see why.
> > Do they not have PHYs?
>
> New Solid Run board MACCHIATObin Single Shot doesn't has 3310 PHY either, like DB boards.
> https://www.cnx-software.com/2017/12/20/solidrun-macchiatobin-single-shot-networking-board-launched-for-269-and-up/

Correct, but this DTS is wrong. It connects to a SFP cage, and as SFP
cages are supported in mainline now, there's no need to mess around
with fixed links or similar.

I haven't tested phylink in that configuration yet as SolidRun haven't
sent me a SingleShot board yet - and I need any board I do get to have
the pull-up resistors on the I2C lines of the correct value, because
I'm not risking corruption of the EEPROMs in my SFP* modules.

--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

2018-03-19 13:08:18

by Stefan Chulski

[permalink] [raw]
Subject: RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation



> -----Original Message-----
> From: Andrew Lunn [mailto:[email protected]]
> Sent: Monday, March 19, 2018 3:00 PM
> To: Antoine Tenart <[email protected]>
> Cc: Russell King - ARM Linux <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Nadav Haklai <[email protected]>; Stefan
> Chulski <[email protected]>; Yan Markman <[email protected]>;
> [email protected]; [email protected]
> Subject: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR
> interface to use in-band negotiation
>
> External Email
>
> ----------------------------------------------------------------------
> Hi Antoine
>
> > You guessed right, that's exactly my use case. The DB boards (7k and
> > 8k) have 10G interfaces without PHYs.
>
> If they don't have PHYs, how are the connected to the outside world?
>
> Andrew

By external SFP or direct attached cable.

Stefan.

2018-03-19 13:11:21

by Andrew Lunn

[permalink] [raw]
Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

> > If they don't have PHYs, how are the connected to the outside world?
> >
> > Andrew
>
> By external SFP or direct attached cable.

Maybe i'm missing something, but don't you just need to add an SFP
device in the device tree. The SFP code and PHYLINK will work
together, query what the SFP module is, use the GPIOs to determine
link up/down and module present, and tell the MAC how to configure the
MAC-SFP link?

Andrew

2018-03-19 13:15:02

by Antoine Tenart

[permalink] [raw]
Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 02:08:23PM +0100, Andrew Lunn wrote:
> > > If they don't have PHYs, how are the connected to the outside world?
> >
> > By external SFP or direct attached cable.
>
> Maybe i'm missing something, but don't you just need to add an SFP
> device in the device tree. The SFP code and PHYLINK will work
> together, query what the SFP module is, use the GPIOs to determine
> link up/down and module present, and tell the MAC how to configure the
> MAC-SFP link?

This would definitively work for SFP connectors with a PHY, but would
that work when using direct attached cable? As in the second case
phylink wouldn't be able to ask the SFP PHY for the link state.

Antoine

--
Antoine T?nart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

2018-03-19 13:19:51

by Russell King (Oracle)

[permalink] [raw]
Subject: Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 02:10:09PM +0100, Antoine Tenart wrote:
> Hi Andrew,
>
> On Mon, Mar 19, 2018 at 01:59:53PM +0100, Andrew Lunn wrote:
> >
> > If they don't have PHYs, how are the connected to the outside world?
>
> On 7k/8k you have the following scheme for 10G only interfaces:
>
> MAC -- Comphy -- PHY -- SFP cage -- ...
>
> Or
>
> MAC -- Comphy -- SFP cage -- ...
>
> The comphy provides serdes lanes, and can be configured in various
> modes (SGMII, 2500SGMII, 10GKR...).

Right - the correct mode is dependent on the SFP module plugged into
the cage. Trying to describe this by ignoring the SFP cage isn't
going to work out well for end-user functionality, though is fine if
you're just hacking a configuration to test (which would not be
suitable for mainline kernels!)

As I've recently replied to Yan, this is a configuration I haven't
tested yet, and it's entirely possible that phylink may need some
tweaks for it.

What you have is a very similar setup to what is on Clearfog with
its SFP cage, where the SFP cage is connected directly to the
Armada 388. That only has to deal with 2500base-X / 1000base-X /
SGMII and not 10G.

What I want is to avoid hacks as much as possible here - if there is
a short-coming with SFP/phylink here, we need to address that
properly.

--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

2018-03-19 13:21:38

by Stefan Chulski

[permalink] [raw]
Subject: RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation



> -----Original Message-----
> From: Andrew Lunn [mailto:[email protected]]
> Sent: Monday, March 19, 2018 3:08 PM
> To: Stefan Chulski <[email protected]>
> Cc: Antoine Tenart <[email protected]>; Russell King - ARM Linux
> <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; Nadav Haklai
> <[email protected]>; Yan Markman <[email protected]>;
> [email protected]; [email protected]
> Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR
> interface to use in-band negotiation
>
> > > If they don't have PHYs, how are the connected to the outside world?
> > >
> > > Andrew
> >
> > By external SFP or direct attached cable.
>
> Maybe i'm missing something, but don't you just need to add an SFP device
> in the device tree. The SFP code and PHYLINK will work together, query what
> the SFP module is, use the GPIOs to determine link up/down and module
> present, and tell the MAC how to configure the MAC-SFP link?
>
> Andrew

phylink pool SFP loss signal to determine link up/down?

Stefan,
Best Regards.

2018-03-19 13:24:42

by Andrew Lunn

[permalink] [raw]
Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

> phylink pool SFP loss signal to determine link up/down?

Yes, the SFP driver will act on a GPIO for link up/down, and a GPIO
for module prescience. When it detects an SFP module hotplugged, it
reads the EEPROM to find out what sort of module it is, and what mode
should be used between the MAC and SFP module. It will also handle if
the SFP module is copper, and has a PHY in it...

Andrew

2018-03-19 13:26:05

by Andrew Lunn

[permalink] [raw]
Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

> This would definitively work for SFP connectors with a PHY, but would
> that work when using direct attached cable?

Then you need to know what is on the other end of the cable? A switch?
A PHY? and SFP module?

Andrew

2018-03-19 13:27:56

by Antoine Tenart

[permalink] [raw]
Subject: Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

Hi Russell,

On Mon, Mar 19, 2018 at 01:18:05PM +0000, Russell King - ARM Linux wrote:
> On Mon, Mar 19, 2018 at 02:10:09PM +0100, Antoine Tenart wrote:
> >
> > On 7k/8k you have the following scheme for 10G only interfaces:
> >
> > MAC -- Comphy -- PHY -- SFP cage -- ...
> >
> > Or
> >
> > MAC -- Comphy -- SFP cage -- ...
> >
> > The comphy provides serdes lanes, and can be configured in various
> > modes (SGMII, 2500SGMII, 10GKR...).
>
> Right - the correct mode is dependent on the SFP module plugged into
> the cage. Trying to describe this by ignoring the SFP cage isn't
> going to work out well for end-user functionality, though is fine if
> you're just hacking a configuration to test (which would not be
> suitable for mainline kernels!)
>
> As I've recently replied to Yan, this is a configuration I haven't
> tested yet, and it's entirely possible that phylink may need some
> tweaks for it.
>
> What you have is a very similar setup to what is on Clearfog with
> its SFP cage, where the SFP cage is connected directly to the
> Armada 388. That only has to deal with 2500base-X / 1000base-X /
> SGMII and not 10G.
>
> What I want is to avoid hacks as much as possible here - if there is
> a short-coming with SFP/phylink here, we need to address that
> properly.

OK. So the proper solution would be to properly describe the SFP cages
in the device tree (and check if phylink deals with it nicely).

I'll update the patches in this way.

Thanks for the feedback,
Antoine

--
Antoine T?nart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

2018-03-19 13:44:24

by Russell King (Oracle)

[permalink] [raw]
Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 01:19:24PM +0000, Stefan Chulski wrote:
>
>
> > -----Original Message-----
> > From: Andrew Lunn [mailto:[email protected]]
> > Sent: Monday, March 19, 2018 3:08 PM
> > To: Stefan Chulski <[email protected]>
> > Cc: Antoine Tenart <[email protected]>; Russell King - ARM Linux
> > <[email protected]>; [email protected]; [email protected];
> > [email protected]; [email protected];
> > [email protected]; [email protected]; linux-
> > [email protected]; [email protected];
> > [email protected]; [email protected]; Nadav Haklai
> > <[email protected]>; Yan Markman <[email protected]>;
> > [email protected]; [email protected]
> > Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR
> > interface to use in-band negotiation
> >
> > > > If they don't have PHYs, how are the connected to the outside world?
> > > >
> > > > Andrew
> > >
> > > By external SFP or direct attached cable.
> >
> > Maybe i'm missing something, but don't you just need to add an SFP device
> > in the device tree. The SFP code and PHYLINK will work together, query what
> > the SFP module is, use the GPIOs to determine link up/down and module
> > present, and tell the MAC how to configure the MAC-SFP link?
> >
> > Andrew
>
> phylink pool SFP loss signal to determine link up/down?

No. Phylink was merged along with SFP cage support, which includes a DT
description for SFP cages, including the various signals for the cage.

The SFP layer will take care of monitoring the cage and conveying state
information to Phylink.

Phylink's job is to work out how any SFP module, PHY and MAC should be
configured and to determine the link state based on information supplied
by or requested from each depending on the configured state.

Please do not try and support SFP cages as fixed links. They aren't,
and such an approach will always have sub-standard link state monitoring.

In an optical setup, the SFP LOS signal just indicates whether there is
sufficient optical power present at the receiver. It doesn't indicate
whether there is a valid signal there, or whether the chip at the other
end of the serdes link can decode the signal. That has to come from the
upstream chip, whether it be a PHY or a MAC.

SFP optical modules do not perform protocol validation - they merely
convert the serdes electrical signal into a light signal and back again,
with varying amounts of monitoring on board.

--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

2018-03-19 14:51:21

by Stefan Chulski

[permalink] [raw]
Subject: RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

> > > There is no inband negotiation like there is with 802.3z or SGMII,
> > > so this makes no sense.
> >
> > Oh, that's what I feared. I read some docs but probably will need more
> > :)
> >
> > Anyway, the reason to use in-band negotiation was also to avoid using
> > fixed-link. It would work but always report the link is up, which for
> > the user isn't a great experience as we have a way to detect this.
> >
> > What would you suggest to achieve this in a reasonable way?
>
> The intention of this test in phylink_of_phy_connect() is to avoid failing
> when there is no requirement for a PHY to be present (such as a fixed link, or
> an 802.3z link.) However, with 10G PHYs such as the 3310, we need the PHY
> so we can read the speed from it, and so know whether to downgrade the
> MAC to SGMII mode, or having downgraded the MAC, upgrade it back to 10G
> mode when the PHY switches to 10G.
>
> I'm guessing that you're wanting this for the DB boards, but I don't see why.
> Do they not have PHYs?

New Solid Run board MACCHIATObin Single Shot doesn't has 3310 PHY either, like DB boards.
https://www.cnx-software.com/2017/12/20/solidrun-macchiatobin-single-shot-networking-board-launched-for-269-and-up/

Stefan,
Best Regards.

2018-03-19 14:51:25

by Antoine Tenart

[permalink] [raw]
Subject: Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

Hi Andrew,

On Mon, Mar 19, 2018 at 01:59:53PM +0100, Andrew Lunn wrote:
>
> If they don't have PHYs, how are the connected to the outside world?

On 7k/8k you have the following scheme for 10G only interfaces:

MAC -- Comphy -- PHY -- SFP cage -- ...

Or

MAC -- Comphy -- SFP cage -- ...

The comphy provides serdes lanes, and can be configured in various
modes (SGMII, 2500SGMII, 10GKR...).

Antoine

--
Antoine T?nart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

2018-03-19 14:52:06

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

Hi Antoine

> You guessed right, that's exactly my use case. The DB boards (7k and 8k)
> have 10G interfaces without PHYs.

If they don't have PHYs, how are the connected to the outside world?

Andrew