* [PATCH net-next 00/10] net: mvpp2: phylink conversion
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 00/10] net: mvpp2: phylink conversion
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: ymarkman, Antoine Tenart, netdev, linux-kernel,
maxime.chevallier, nadavh, thomas.petazzoni, miquel.raynal,
stefanc, mw, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 00/10] net: mvpp2: phylink conversion
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 01/10] net: mvpp2: align the ethtool ops definition
2018-03-16 10:33 ` Antoine Tenart
@ 2018-03-16 10:33 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 01/10] net: mvpp2: align the ethtool ops definition
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-16 10:33 ` Antoine Tenart
(?)
@ 2018-03-16 10:33 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: ymarkman, Antoine Tenart, netdev, linux-kernel,
maxime.chevallier, nadavh, thomas.petazzoni, miquel.raynal,
stefanc, mw, linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 03/10] net: mvpp2: phylink support
2018-03-16 10:33 ` Antoine Tenart
@ 2018-03-16 10:33 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 03/10] net: mvpp2: phylink support
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 04/10] phy: add 2.5G SGMII mode to the phy_mode enum
2018-03-16 10:33 ` Antoine Tenart
(?)
@ 2018-03-16 10:33 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 04/10] phy: add 2.5G SGMII mode to the phy_mode enum
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: ymarkman, Antoine Tenart, netdev, linux-kernel,
maxime.chevallier, nadavh, thomas.petazzoni, miquel.raynal,
stefanc, mw, linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 04/10] phy: add 2.5G SGMII mode to the phy_mode enum
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode
2018-03-16 10:33 ` Antoine Tenart
@ 2018-03-16 10:33 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 06/10] net: mvpp2: 1000baseX support
2018-03-16 10:33 ` Antoine Tenart
@ 2018-03-16 10:33 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 06/10] net: mvpp2: 1000baseX support
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 07/10] net: mvpp2: 2500baseX support
2018-03-16 10:33 ` Antoine Tenart
@ 2018-03-16 10:33 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 07/10] net: mvpp2: 2500baseX support
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 08/10] arm64: dts: marvell: 7040-db: set the 10G interface management to in-band
2018-03-16 10:33 ` Antoine Tenart
@ 2018-03-16 10:33 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 08/10] arm64: dts: marvell: 7040-db: set the 10G interface management to in-band
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 09/10] arm64: dts: marvell: 8040-db: set the 10G interfaces management to in-band
2018-03-16 10:33 ` Antoine Tenart
@ 2018-03-16 10:33 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 09/10] arm64: dts: marvell: 8040-db: set the 10G interfaces management to in-band
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 10/10] arm64: dts: marvell: mcbin: enable the fourth network interface
2018-03-16 10:33 ` Antoine Tenart
@ 2018-03-16 10:33 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [PATCH net-next 10/10] arm64: dts: marvell: mcbin: enable the fourth network interface
@ 2018-03-16 10:33 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
---
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
^ permalink raw reply related [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-16 10:33 ` Antoine Tenart
@ 2018-03-16 15:53 ` Russell King - ARM Linux
-1 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-16 15:53 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
> ---
> 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-16 15:53 ` Russell King - ARM Linux
0 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-16 15:53 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
> ---
> 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 03/10] net: mvpp2: phylink support
2018-03-16 10:33 ` Antoine Tenart
@ 2018-03-16 16:03 ` Russell King - ARM Linux
-1 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-16 16:03 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 03/10] net: mvpp2: phylink support
@ 2018-03-16 16:03 ` Russell King - ARM Linux
0 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-16 16:03 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode
2018-03-16 10:33 ` Antoine Tenart
@ 2018-03-18 4:42 ` Baruch Siach
-1 siblings, 0 replies; 81+ messages in thread
From: Baruch Siach @ 2018-03-18 4:42 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth, ymarkman, netdev, linux-kernel,
maxime.chevallier, nadavh, thomas.petazzoni, miquel.raynal,
stefanc, mw, linux-arm-kernel
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 <antoine.tenart@bootlin.com>
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode
@ 2018-03-18 4:42 ` Baruch Siach
0 siblings, 0 replies; 81+ messages in thread
From: Baruch Siach @ 2018-03-18 4:42 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode
2018-03-18 4:42 ` Baruch Siach
@ 2018-03-19 8:44 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 8:44 UTC (permalink / raw)
To: Baruch Siach
Cc: Antoine Tenart, davem, kishon, linux, gregory.clement, andrew,
jason, sebastian.hesselbarth, ymarkman, netdev, linux-kernel,
maxime.chevallier, nadavh, thomas.petazzoni, miquel.raynal,
stefanc, mw, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode
@ 2018-03-19 8:44 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 8:44 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 03/10] net: mvpp2: phylink support
2018-03-16 16:03 ` Russell King - ARM Linux
@ 2018-03-19 8:45 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 8:45 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 03/10] net: mvpp2: phylink support
@ 2018-03-19 8:45 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 8:45 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-16 15:53 ` Russell King - ARM Linux
@ 2018-03-19 8:52 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 8:52 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
> > ---
> > 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 8:52 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 8:52 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
> > ---
> > 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 04/10] phy: add 2.5G SGMII mode to the phy_mode enum
2018-03-16 10:33 ` Antoine Tenart
(?)
@ 2018-03-19 9:46 ` Kishon Vijay Abraham I
-1 siblings, 0 replies; 81+ messages in thread
From: Kishon Vijay Abraham I @ 2018-03-19 9:46 UTC (permalink / raw)
To: Antoine Tenart, davem, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
miquel.raynal, nadavh, stefanc, ymarkman, mw, linux-arm-kernel
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 <antoine.tenart@bootlin.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> 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,
>
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 04/10] phy: add 2.5G SGMII mode to the phy_mode enum
@ 2018-03-19 9:46 ` Kishon Vijay Abraham I
0 siblings, 0 replies; 81+ messages in thread
From: Kishon Vijay Abraham I @ 2018-03-19 9:46 UTC (permalink / raw)
To: Antoine Tenart, davem, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: ymarkman, netdev, linux-kernel, maxime.chevallier, nadavh,
thomas.petazzoni, miquel.raynal, stefanc, mw, linux-arm-kernel
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 <antoine.tenart@bootlin.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> 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,
>
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 04/10] phy: add 2.5G SGMII mode to the phy_mode enum
@ 2018-03-19 9:46 ` Kishon Vijay Abraham I
0 siblings, 0 replies; 81+ messages in thread
From: Kishon Vijay Abraham I @ 2018-03-19 9:46 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> 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,
>
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 8:52 ` Antoine Tenart
@ 2018-03-19 11:12 ` Russell King - ARM Linux
-1 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-19 11:12 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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 <antoine.tenart@bootlin.com>
> > > ---
> > > 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 11:12 ` Russell King - ARM Linux
0 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-19 11:12 UTC (permalink / raw)
To: linux-arm-kernel
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 <antoine.tenart@bootlin.com>
> > > ---
> > > 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 11:12 ` Russell King - ARM Linux
@ 2018-03-19 12:52 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 12:52 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 12:52 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 12:52 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 11:12 ` Russell King - ARM Linux
@ 2018-03-19 12:58 ` Stefan Chulski
-1 siblings, 0 replies; 81+ messages in thread
From: Stefan Chulski @ 2018-03-19 12:58 UTC (permalink / raw)
To: Russell King - ARM Linux, Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, Nadav Haklai, Yan Markman, mw,
linux-arm-kernel
> > > 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.
^ permalink raw reply [flat|nested] 81+ messages in thread
* [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 12:58 ` Stefan Chulski
0 siblings, 0 replies; 81+ messages in thread
From: Stefan Chulski @ 2018-03-19 12:58 UTC (permalink / raw)
To: linux-arm-kernel
> > > 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.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 12:52 ` Antoine Tenart
@ 2018-03-19 12:59 ` Andrew Lunn
-1 siblings, 0 replies; 81+ messages in thread
From: Andrew Lunn @ 2018-03-19 12:59 UTC (permalink / raw)
To: Antoine Tenart
Cc: Russell King - ARM Linux, davem, kishon, gregory.clement, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 12:59 ` Andrew Lunn
0 siblings, 0 replies; 81+ messages in thread
From: Andrew Lunn @ 2018-03-19 12:59 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 12:58 ` Stefan Chulski
(?)
@ 2018-03-19 13:01 ` Yan Markman
-1 siblings, 0 replies; 81+ messages in thread
From: Yan Markman @ 2018-03-19 13:01 UTC (permalink / raw)
To: Stefan Chulski, Russell King - ARM Linux, Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, Nadav Haklai, mw,
linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]
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 <linux@armlinux.org.uk>; Antoine Tenart <antoine.tenart@bootlin.com>
Cc: davem@davemloft.net; kishon@ti.com; gregory.clement@bootlin.com; andrew@lunn.ch; jason@lakedaemon.net; sebastian.hesselbarth@gmail.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>; mw@semihalf.com; linux-arm-kernel@lists.infradead.org
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.
[-- Attachment #2: 0001-arm64-dts-marvell-add-new-mcbin-single-shot-board.patch --]
[-- Type: application/octet-stream, Size: 9179 bytes --]
From 7e4cd12ef1111f85778f1ef2afb3b1b7839dee14 Mon Sep 17 00:00:00 2001
From: Yan Markman <ymarkman@marvell.com>
Date: Mon, 12 Mar 2018 18:08:02 +0200
Subject: [PATCH 1/1] arm64: dts: marvell: add new mcbin-single-shot board
Add new Macchiato version board which has single physical
interface on ports 0 -- only Fiber and no Copper.
The only difference is - no phy node declaration
Change-Id: Ia5876f6371d897c2f29736f623a57f9eb2a69365
Signed-off-by: Yan Markman <ymarkman@marvell.com>
---
arch/arm64/boot/dts/marvell/Makefile | 1 +
.../dts/marvell/armada-8040-mcbin-single-shot.dts | 323 +++++++++++++++++++++
2 files changed, 324 insertions(+)
create mode 100755 arch/arm64/boot/dts/marvell/armada-8040-mcbin-single-shot.dts
diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 5633676..8051c0d 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin-single-shot.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8080-db.dtb
always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin-single-shot.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin-single-shot.dts
new file mode 100755
index 0000000..12eda12
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin-single-shot.dts
@@ -0,0 +1,323 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for MACCHIATOBin Armada 8040 community board platform
+ */
+
+#include "armada-8040.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "Marvell 8040 MACHIATOBin SingleShot";
+ compatible = "marvell,armada8040-mcbin-single-shot",
+ "marvell,armada8040-mcbin", "marvell,armada8040",
+ "marvell,armada-ap806-quad", "marvell,armada-ap806";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@00000000 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x80000000>;
+ };
+
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cps_eth0;
+ ethernet2 = &cps_eth1;
+ ethernet3 = &cps_eth2;
+ };
+
+ /* Regulator labels correspond with schematics */
+ v_3_3: regulator-3-3v {
+ compatible = "regulator-fixed";
+ regulator-name = "v_3_3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ status = "okay";
+ };
+
+ v_vddo_h: regulator-1-8v {
+ compatible = "regulator-fixed";
+ regulator-name = "v_vddo_h";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ status = "okay";
+ };
+
+ v_5v0_usb3_hst_vbus: regulator-usb3-vbus0 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&cpm_gpio2 15 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_xhci_vbus_pins>;
+ regulator-name = "v_5v0_usb3_hst_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ status = "okay";
+ };
+
+ usb3h0_phy: usb3_phy0 {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <&v_5v0_usb3_hst_vbus>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+ pinctrl-0 = <&uart0_pins>;
+ pinctrl-names = "default";
+};
+
+&ap_sdhci0 {
+ bus-width = <8>;
+ /*
+ * Not stable in HS modes - phy needs "more calibration", so add
+ * the "slow-mode" and disable SDR104, SDR50 and DDR50 modes.
+ */
+ marvell,xenon-phy-slow-mode;
+ no-1-8-v;
+ no-sd;
+ no-sdio;
+ non-removable;
+ status = "okay";
+ vqmmc-supply = <&v_vddo_h>;
+};
+
+&cpm_i2c0 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_i2c0_pins>;
+ status = "okay";
+};
+
+&cpm_i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_i2c1_pins>;
+ status = "okay";
+
+ i2c-switch@70 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+
+ sfpp0_i2c: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+ sfpp1_i2c: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ sfp_1g_i2c: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+ };
+};
+
+&cpm_mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_ge_mdio_pins>;
+ status = "okay";
+
+ ge_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&cpm_pcie0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_pcie_pins>;
+ num-lanes = <4>;
+ num-viewport = <8>;
+ reset-gpio = <&cpm_gpio1 20 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&cpm_pinctrl {
+ cpm_ge_mdio_pins: ge-mdio-pins {
+ marvell,pins = "mpp32", "mpp34";
+ marvell,function = "ge";
+ };
+ cpm_i2c1_pins: i2c1-pins {
+ marvell,pins = "mpp35", "mpp36";
+ marvell,function = "i2c1";
+ };
+ cpm_i2c0_pins: i2c0-pins {
+ marvell,pins = "mpp37", "mpp38";
+ marvell,function = "i2c0";
+ };
+ cpm_xhci_vbus_pins: xhci0-vbus-pins {
+ marvell,pins = "mpp47";
+ marvell,function = "gpio";
+ };
+ cpm_pcie_pins: pcie-pins {
+ marvell,pins = "mpp52";
+ marvell,function = "gpio";
+ };
+ cpm_sdhci_pins: sdhci-pins {
+ marvell,pins = "mpp55", "mpp56", "mpp57", "mpp58", "mpp59",
+ "mpp60", "mpp61";
+ marvell,function = "sdio";
+ };
+};
+
+&cpm_xmdio {
+ status = "okay";
+
+ phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0>;
+ };
+
+ phy8: ethernet-phy@8 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <8>;
+ };
+};
+
+&cpm_ethernet {
+ status = "okay";
+};
+
+&cpm_eth0 {
+ status = "okay";
+ phy-mode = "10gbase-kr";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cpm_comphy4 0>;
+};
+
+&cpm_sata0 {
+ /* CPM Lane 0 - U29 */
+ status = "okay";
+};
+
+&cpm_sdhci0 {
+ /* U6 */
+ broken-cd;
+ bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_sdhci_pins>;
+ status = "okay";
+ vqmmc-supply = <&v_3_3>;
+};
+
+&cpm_usb3_0 {
+ /* J38? - USB2.0 only */
+ status = "okay";
+};
+
+&cpm_usb3_1 {
+ /* J38? - USB2.0 only */
+ status = "okay";
+};
+
+&cps_ethernet {
+ status = "okay";
+};
+
+&cps_eth0 {
+ status = "okay";
+ phy-mode = "10gbase-kr";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cps_comphy4 0>;
+};
+
+&cps_eth1 {
+ /* CPS Lane 0 - J5 (Gigabit RJ45) */
+ status = "okay";
+ /* Network PHY */
+ phy = <&ge_phy>;
+ phy-mode = "sgmii";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cps_comphy0 1>;
+};
+
+&cps_eth2 {
+ /* CPS Lane 5 */
+ status = "okay";
+ phy-mode = "2500base-x";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cps_comphy5 2>;
+};
+
+&cps_pinctrl {
+ cps_spi1_pins: spi1-pins {
+ marvell,pins = "mpp12", "mpp13", "mpp14", "mpp15", "mpp16";
+ marvell,function = "spi1";
+ };
+};
+
+&cps_sata0 {
+ /* CPS Lane 1 - U32 */
+ /* CPS Lane 3 - U31 */
+ status = "okay";
+};
+
+&cps_spi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cps_spi1_pins>;
+ status = "okay";
+
+ spi-flash@0 {
+ compatible = "st,w25q32";
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+ };
+};
+
+&cps_usb3_0 {
+ /* CPS Lane 2 - CON7 */
+ usb-phy = <&usb3h0_phy>;
+ status = "okay";
+};
--
2.0.4
^ permalink raw reply related [flat|nested] 81+ messages in thread
* RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:01 ` Yan Markman
0 siblings, 0 replies; 81+ messages in thread
From: Yan Markman @ 2018-03-19 13:01 UTC (permalink / raw)
To: Stefan Chulski, Russell King - ARM Linux, Antoine Tenart
Cc: andrew, mw, jason, netdev, gregory.clement, linux-kernel, kishon,
Nadav Haklai, thomas.petazzoni, miquel.raynal, maxime.chevallier,
davem, linux-arm-kernel, sebastian.hesselbarth
[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]
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 <linux@armlinux.org.uk>; Antoine Tenart <antoine.tenart@bootlin.com>
Cc: davem@davemloft.net; kishon@ti.com; gregory.clement@bootlin.com; andrew@lunn.ch; jason@lakedaemon.net; sebastian.hesselbarth@gmail.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>; mw@semihalf.com; linux-arm-kernel@lists.infradead.org
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.
[-- Attachment #2: 0001-arm64-dts-marvell-add-new-mcbin-single-shot-board.patch --]
[-- Type: application/octet-stream, Size: 9179 bytes --]
From 7e4cd12ef1111f85778f1ef2afb3b1b7839dee14 Mon Sep 17 00:00:00 2001
From: Yan Markman <ymarkman@marvell.com>
Date: Mon, 12 Mar 2018 18:08:02 +0200
Subject: [PATCH 1/1] arm64: dts: marvell: add new mcbin-single-shot board
Add new Macchiato version board which has single physical
interface on ports 0 -- only Fiber and no Copper.
The only difference is - no phy node declaration
Change-Id: Ia5876f6371d897c2f29736f623a57f9eb2a69365
Signed-off-by: Yan Markman <ymarkman@marvell.com>
---
arch/arm64/boot/dts/marvell/Makefile | 1 +
.../dts/marvell/armada-8040-mcbin-single-shot.dts | 323 +++++++++++++++++++++
2 files changed, 324 insertions(+)
create mode 100755 arch/arm64/boot/dts/marvell/armada-8040-mcbin-single-shot.dts
diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 5633676..8051c0d 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin-single-shot.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8080-db.dtb
always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin-single-shot.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin-single-shot.dts
new file mode 100755
index 0000000..12eda12
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin-single-shot.dts
@@ -0,0 +1,323 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for MACCHIATOBin Armada 8040 community board platform
+ */
+
+#include "armada-8040.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "Marvell 8040 MACHIATOBin SingleShot";
+ compatible = "marvell,armada8040-mcbin-single-shot",
+ "marvell,armada8040-mcbin", "marvell,armada8040",
+ "marvell,armada-ap806-quad", "marvell,armada-ap806";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@00000000 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x80000000>;
+ };
+
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cps_eth0;
+ ethernet2 = &cps_eth1;
+ ethernet3 = &cps_eth2;
+ };
+
+ /* Regulator labels correspond with schematics */
+ v_3_3: regulator-3-3v {
+ compatible = "regulator-fixed";
+ regulator-name = "v_3_3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ status = "okay";
+ };
+
+ v_vddo_h: regulator-1-8v {
+ compatible = "regulator-fixed";
+ regulator-name = "v_vddo_h";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ status = "okay";
+ };
+
+ v_5v0_usb3_hst_vbus: regulator-usb3-vbus0 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&cpm_gpio2 15 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_xhci_vbus_pins>;
+ regulator-name = "v_5v0_usb3_hst_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ status = "okay";
+ };
+
+ usb3h0_phy: usb3_phy0 {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <&v_5v0_usb3_hst_vbus>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+ pinctrl-0 = <&uart0_pins>;
+ pinctrl-names = "default";
+};
+
+&ap_sdhci0 {
+ bus-width = <8>;
+ /*
+ * Not stable in HS modes - phy needs "more calibration", so add
+ * the "slow-mode" and disable SDR104, SDR50 and DDR50 modes.
+ */
+ marvell,xenon-phy-slow-mode;
+ no-1-8-v;
+ no-sd;
+ no-sdio;
+ non-removable;
+ status = "okay";
+ vqmmc-supply = <&v_vddo_h>;
+};
+
+&cpm_i2c0 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_i2c0_pins>;
+ status = "okay";
+};
+
+&cpm_i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_i2c1_pins>;
+ status = "okay";
+
+ i2c-switch@70 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+
+ sfpp0_i2c: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+ sfpp1_i2c: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ sfp_1g_i2c: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+ };
+};
+
+&cpm_mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_ge_mdio_pins>;
+ status = "okay";
+
+ ge_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&cpm_pcie0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_pcie_pins>;
+ num-lanes = <4>;
+ num-viewport = <8>;
+ reset-gpio = <&cpm_gpio1 20 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&cpm_pinctrl {
+ cpm_ge_mdio_pins: ge-mdio-pins {
+ marvell,pins = "mpp32", "mpp34";
+ marvell,function = "ge";
+ };
+ cpm_i2c1_pins: i2c1-pins {
+ marvell,pins = "mpp35", "mpp36";
+ marvell,function = "i2c1";
+ };
+ cpm_i2c0_pins: i2c0-pins {
+ marvell,pins = "mpp37", "mpp38";
+ marvell,function = "i2c0";
+ };
+ cpm_xhci_vbus_pins: xhci0-vbus-pins {
+ marvell,pins = "mpp47";
+ marvell,function = "gpio";
+ };
+ cpm_pcie_pins: pcie-pins {
+ marvell,pins = "mpp52";
+ marvell,function = "gpio";
+ };
+ cpm_sdhci_pins: sdhci-pins {
+ marvell,pins = "mpp55", "mpp56", "mpp57", "mpp58", "mpp59",
+ "mpp60", "mpp61";
+ marvell,function = "sdio";
+ };
+};
+
+&cpm_xmdio {
+ status = "okay";
+
+ phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0>;
+ };
+
+ phy8: ethernet-phy@8 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <8>;
+ };
+};
+
+&cpm_ethernet {
+ status = "okay";
+};
+
+&cpm_eth0 {
+ status = "okay";
+ phy-mode = "10gbase-kr";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cpm_comphy4 0>;
+};
+
+&cpm_sata0 {
+ /* CPM Lane 0 - U29 */
+ status = "okay";
+};
+
+&cpm_sdhci0 {
+ /* U6 */
+ broken-cd;
+ bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_sdhci_pins>;
+ status = "okay";
+ vqmmc-supply = <&v_3_3>;
+};
+
+&cpm_usb3_0 {
+ /* J38? - USB2.0 only */
+ status = "okay";
+};
+
+&cpm_usb3_1 {
+ /* J38? - USB2.0 only */
+ status = "okay";
+};
+
+&cps_ethernet {
+ status = "okay";
+};
+
+&cps_eth0 {
+ status = "okay";
+ phy-mode = "10gbase-kr";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cps_comphy4 0>;
+};
+
+&cps_eth1 {
+ /* CPS Lane 0 - J5 (Gigabit RJ45) */
+ status = "okay";
+ /* Network PHY */
+ phy = <&ge_phy>;
+ phy-mode = "sgmii";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cps_comphy0 1>;
+};
+
+&cps_eth2 {
+ /* CPS Lane 5 */
+ status = "okay";
+ phy-mode = "2500base-x";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cps_comphy5 2>;
+};
+
+&cps_pinctrl {
+ cps_spi1_pins: spi1-pins {
+ marvell,pins = "mpp12", "mpp13", "mpp14", "mpp15", "mpp16";
+ marvell,function = "spi1";
+ };
+};
+
+&cps_sata0 {
+ /* CPS Lane 1 - U32 */
+ /* CPS Lane 3 - U31 */
+ status = "okay";
+};
+
+&cps_spi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cps_spi1_pins>;
+ status = "okay";
+
+ spi-flash@0 {
+ compatible = "st,w25q32";
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+ };
+};
+
+&cps_usb3_0 {
+ /* CPS Lane 2 - CON7 */
+ usb-phy = <&usb3h0_phy>;
+ status = "okay";
+};
--
2.0.4
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 81+ messages in thread
* [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:01 ` Yan Markman
0 siblings, 0 replies; 81+ messages in thread
From: Yan Markman @ 2018-03-19 13:01 UTC (permalink / raw)
To: linux-arm-kernel
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 <linux@armlinux.org.uk>; Antoine Tenart <antoine.tenart@bootlin.com>
Cc: davem at davemloft.net; kishon at ti.com; gregory.clement at bootlin.com; andrew at lunn.ch; jason at lakedaemon.net; sebastian.hesselbarth at gmail.com; netdev at vger.kernel.org; linux-kernel at vger.kernel.org; thomas.petazzoni at bootlin.com; maxime.chevallier at bootlin.com; miquel.raynal at bootlin.com; Nadav Haklai <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>; mw at semihalf.com; linux-arm-kernel at lists.infradead.org
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-arm64-dts-marvell-add-new-mcbin-single-shot-board.patch
Type: application/octet-stream
Size: 9179 bytes
Desc: 0001-arm64-dts-marvell-add-new-mcbin-single-shot-board.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180319/599bd305/attachment-0001.obj>
^ permalink raw reply [flat|nested] 81+ messages in thread
* RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 12:59 ` Andrew Lunn
(?)
@ 2018-03-19 13:03 ` Stefan Chulski
-1 siblings, 0 replies; 81+ messages in thread
From: Stefan Chulski @ 2018-03-19 13:03 UTC (permalink / raw)
To: Andrew Lunn, Antoine Tenart
Cc: Russell King - ARM Linux, davem, kishon, gregory.clement, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, Nadav Haklai, Yan Markman, mw,
linux-arm-kernel
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Monday, March 19, 2018 3:00 PM
> To: Antoine Tenart <antoine.tenart@bootlin.com>
> Cc: Russell King - ARM Linux <linux@armlinux.org.uk>;
> davem@davemloft.net; kishon@ti.com; gregory.clement@bootlin.com;
> jason@lakedaemon.net; sebastian.hesselbarth@gmail.com;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com;
> miquel.raynal@bootlin.com; Nadav Haklai <nadavh@marvell.com>; Stefan
> Chulski <stefanc@marvell.com>; Yan Markman <ymarkman@marvell.com>;
> mw@semihalf.com; linux-arm-kernel@lists.infradead.org
> 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.
^ permalink raw reply [flat|nested] 81+ messages in thread
* RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:03 ` Stefan Chulski
0 siblings, 0 replies; 81+ messages in thread
From: Stefan Chulski @ 2018-03-19 13:03 UTC (permalink / raw)
To: Andrew Lunn, Antoine Tenart
Cc: mw, Yan Markman, jason, netdev, gregory.clement,
Russell King - ARM Linux, kishon, Nadav Haklai, linux-arm-kernel,
thomas.petazzoni, miquel.raynal, maxime.chevallier, davem,
linux-kernel, sebastian.hesselbarth
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Monday, March 19, 2018 3:00 PM
> To: Antoine Tenart <antoine.tenart@bootlin.com>
> Cc: Russell King - ARM Linux <linux@armlinux.org.uk>;
> davem@davemloft.net; kishon@ti.com; gregory.clement@bootlin.com;
> jason@lakedaemon.net; sebastian.hesselbarth@gmail.com;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com;
> miquel.raynal@bootlin.com; Nadav Haklai <nadavh@marvell.com>; Stefan
> Chulski <stefanc@marvell.com>; Yan Markman <ymarkman@marvell.com>;
> mw@semihalf.com; linux-arm-kernel@lists.infradead.org
> 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.
^ permalink raw reply [flat|nested] 81+ messages in thread
* [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:03 ` Stefan Chulski
0 siblings, 0 replies; 81+ messages in thread
From: Stefan Chulski @ 2018-03-19 13:03 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew at lunn.ch]
> Sent: Monday, March 19, 2018 3:00 PM
> To: Antoine Tenart <antoine.tenart@bootlin.com>
> Cc: Russell King - ARM Linux <linux@armlinux.org.uk>;
> davem at davemloft.net; kishon at ti.com; gregory.clement at bootlin.com;
> jason at lakedaemon.net; sebastian.hesselbarth at gmail.com;
> netdev at vger.kernel.org; linux-kernel at vger.kernel.org;
> thomas.petazzoni at bootlin.com; maxime.chevallier at bootlin.com;
> miquel.raynal at bootlin.com; Nadav Haklai <nadavh@marvell.com>; Stefan
> Chulski <stefanc@marvell.com>; Yan Markman <ymarkman@marvell.com>;
> mw at semihalf.com; linux-arm-kernel at lists.infradead.org
> 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.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 13:01 ` Yan Markman
(?)
@ 2018-03-19 13:05 ` Russell King - ARM Linux
-1 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-19 13:05 UTC (permalink / raw)
To: Yan Markman
Cc: Stefan Chulski, Antoine Tenart, davem, kishon, gregory.clement,
andrew, jason, sebastian.hesselbarth, netdev, linux-kernel,
thomas.petazzoni, maxime.chevallier, miquel.raynal, Nadav Haklai,
mw, linux-arm-kernel
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 <linux@armlinux.org.uk>; Antoine Tenart <antoine.tenart@bootlin.com>
> Cc: davem@davemloft.net; kishon@ti.com; gregory.clement@bootlin.com; andrew@lunn.ch; jason@lakedaemon.net; sebastian.hesselbarth@gmail.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>; mw@semihalf.com; linux-arm-kernel@lists.infradead.org
> 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:05 ` Russell King - ARM Linux
0 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-19 13:05 UTC (permalink / raw)
To: Yan Markman
Cc: Stefan Chulski, Antoine Tenart, davem, kishon, gregory.clement,
andrew, jason, sebastian.hesselbarth, netdev, linux-kernel,
thomas.petazzoni, maxime.chevallier, miquel.raynal, Nadav Haklai,
mw,
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 <linux@armlinux.org.uk>; Antoine Tenart <antoine.tenart@bootlin.com>
> Cc: davem@davemloft.net; kishon@ti.com; gregory.clement@bootlin.com; andrew@lunn.ch; jason@lakedaemon.net; sebastian.hesselbarth@gmail.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>; mw@semihalf.com; linux-arm-kernel@lists.infradead.org
> 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:05 ` Russell King - ARM Linux
0 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-19 13:05 UTC (permalink / raw)
To: linux-arm-kernel
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 <linux@armlinux.org.uk>; Antoine Tenart <antoine.tenart@bootlin.com>
> Cc: davem at davemloft.net; kishon at ti.com; gregory.clement at bootlin.com; andrew at lunn.ch; jason at lakedaemon.net; sebastian.hesselbarth at gmail.com; netdev at vger.kernel.org; linux-kernel at vger.kernel.org; thomas.petazzoni at bootlin.com; maxime.chevallier at bootlin.com; miquel.raynal at bootlin.com; Nadav Haklai <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>; mw at semihalf.com; linux-arm-kernel at lists.infradead.org
> 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 13:03 ` Stefan Chulski
(?)
@ 2018-03-19 13:08 ` Andrew Lunn
-1 siblings, 0 replies; 81+ messages in thread
From: Andrew Lunn @ 2018-03-19 13:08 UTC (permalink / raw)
To: Stefan Chulski
Cc: Antoine Tenart, Russell King - ARM Linux, davem, kishon,
gregory.clement, jason, sebastian.hesselbarth, netdev,
linux-kernel, thomas.petazzoni, maxime.chevallier, miquel.raynal,
Nadav Haklai, Yan Markman, mw, linux-arm-kernel
> > 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:08 ` Andrew Lunn
0 siblings, 0 replies; 81+ messages in thread
From: Andrew Lunn @ 2018-03-19 13:08 UTC (permalink / raw)
To: Stefan Chulski
Cc: Antoine Tenart, Russell King - ARM Linux, davem, kishon,
gregory.clement, jason, sebastian.hesselbarth, netdev,
linux-kernel, thomas.petazzoni, maxime.chevallier, miquel.raynal,
Nadav Haklai, Yan Markman, mw,
> > 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:08 ` Andrew Lunn
0 siblings, 0 replies; 81+ messages in thread
From: Andrew Lunn @ 2018-03-19 13:08 UTC (permalink / raw)
To: linux-arm-kernel
> > 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 12:59 ` Andrew Lunn
@ 2018-03-19 13:10 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 13:10 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, Russell King - ARM Linux, davem, kishon,
gregory.clement, jason, sebastian.hesselbarth, netdev,
linux-kernel, thomas.petazzoni, maxime.chevallier, miquel.raynal,
nadavh, stefanc, ymarkman, mw, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:10 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 13:10 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 13:08 ` Andrew Lunn
(?)
@ 2018-03-19 13:13 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 13:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: Stefan Chulski, Antoine Tenart, Russell King - ARM Linux, davem,
kishon, gregory.clement, jason, sebastian.hesselbarth, netdev,
linux-kernel, thomas.petazzoni, maxime.chevallier, miquel.raynal,
Nadav Haklai, Yan Markman, mw, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:13 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 13:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: Stefan Chulski, Antoine Tenart, Russell King - ARM Linux, davem,
kishon, gregory.clement, jason, sebastian.hesselbarth, netdev,
linux-kernel, thomas.petazzoni, maxime.chevallier, miquel.raynal,
Nadav Haklai, Yan Markman, mw@semihalf.com
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:13 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 13:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 13:10 ` Antoine Tenart
@ 2018-03-19 13:18 ` Russell King - ARM Linux
-1 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-19 13:18 UTC (permalink / raw)
To: Antoine Tenart
Cc: Andrew Lunn, davem, kishon, gregory.clement, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:18 ` Russell King - ARM Linux
0 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-19 13:18 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 13:08 ` Andrew Lunn
(?)
@ 2018-03-19 13:19 ` Stefan Chulski
-1 siblings, 0 replies; 81+ messages in thread
From: Stefan Chulski @ 2018-03-19 13:19 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, Russell King - ARM Linux, davem, kishon,
gregory.clement, jason, sebastian.hesselbarth, netdev,
linux-kernel, thomas.petazzoni, maxime.chevallier, miquel.raynal,
Nadav Haklai, Yan Markman, mw, linux-arm-kernel
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Monday, March 19, 2018 3:08 PM
> To: Stefan Chulski <stefanc@marvell.com>
> Cc: Antoine Tenart <antoine.tenart@bootlin.com>; Russell King - ARM Linux
> <linux@armlinux.org.uk>; davem@davemloft.net; kishon@ti.com;
> gregory.clement@bootlin.com; jason@lakedaemon.net;
> sebastian.hesselbarth@gmail.com; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; thomas.petazzoni@bootlin.com;
> maxime.chevallier@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai
> <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>;
> mw@semihalf.com; linux-arm-kernel@lists.infradead.org
> 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.
^ permalink raw reply [flat|nested] 81+ messages in thread
* RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:19 ` Stefan Chulski
0 siblings, 0 replies; 81+ messages in thread
From: Stefan Chulski @ 2018-03-19 13:19 UTC (permalink / raw)
To: Andrew Lunn
Cc: mw, Yan Markman, jason, Antoine Tenart, netdev, gregory.clement,
Russell King - ARM Linux, kishon, Nadav Haklai, linux-arm-kernel,
thomas.petazzoni, miquel.raynal, maxime.chevallier, davem,
linux-kernel, sebastian.hesselbarth
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Monday, March 19, 2018 3:08 PM
> To: Stefan Chulski <stefanc@marvell.com>
> Cc: Antoine Tenart <antoine.tenart@bootlin.com>; Russell King - ARM Linux
> <linux@armlinux.org.uk>; davem@davemloft.net; kishon@ti.com;
> gregory.clement@bootlin.com; jason@lakedaemon.net;
> sebastian.hesselbarth@gmail.com; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; thomas.petazzoni@bootlin.com;
> maxime.chevallier@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai
> <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>;
> mw@semihalf.com; linux-arm-kernel@lists.infradead.org
> 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.
^ permalink raw reply [flat|nested] 81+ messages in thread
* [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:19 ` Stefan Chulski
0 siblings, 0 replies; 81+ messages in thread
From: Stefan Chulski @ 2018-03-19 13:19 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew at lunn.ch]
> Sent: Monday, March 19, 2018 3:08 PM
> To: Stefan Chulski <stefanc@marvell.com>
> Cc: Antoine Tenart <antoine.tenart@bootlin.com>; Russell King - ARM Linux
> <linux@armlinux.org.uk>; davem at davemloft.net; kishon at ti.com;
> gregory.clement at bootlin.com; jason at lakedaemon.net;
> sebastian.hesselbarth at gmail.com; netdev at vger.kernel.org; linux-
> kernel at vger.kernel.org; thomas.petazzoni at bootlin.com;
> maxime.chevallier at bootlin.com; miquel.raynal at bootlin.com; Nadav Haklai
> <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>;
> mw at semihalf.com; linux-arm-kernel at lists.infradead.org
> 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.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 13:19 ` Stefan Chulski
(?)
@ 2018-03-19 13:23 ` Andrew Lunn
-1 siblings, 0 replies; 81+ messages in thread
From: Andrew Lunn @ 2018-03-19 13:23 UTC (permalink / raw)
To: Stefan Chulski
Cc: Antoine Tenart, Russell King - ARM Linux, davem, kishon,
gregory.clement, jason, sebastian.hesselbarth, netdev,
linux-kernel, thomas.petazzoni, maxime.chevallier, miquel.raynal,
Nadav Haklai, Yan Markman, mw, linux-arm-kernel
> 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:23 ` Andrew Lunn
0 siblings, 0 replies; 81+ messages in thread
From: Andrew Lunn @ 2018-03-19 13:23 UTC (permalink / raw)
To: Stefan Chulski
Cc: Antoine Tenart, Russell King - ARM Linux, davem, kishon,
gregory.clement, jason, sebastian.hesselbarth, netdev,
linux-kernel, thomas.petazzoni, maxime.chevallier, miquel.raynal,
Nadav Haklai, Yan Markman, mw,
> 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:23 ` Andrew Lunn
0 siblings, 0 replies; 81+ messages in thread
From: Andrew Lunn @ 2018-03-19 13:23 UTC (permalink / raw)
To: linux-arm-kernel
> 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 13:13 ` Antoine Tenart
(?)
@ 2018-03-19 13:24 ` Andrew Lunn
-1 siblings, 0 replies; 81+ messages in thread
From: Andrew Lunn @ 2018-03-19 13:24 UTC (permalink / raw)
To: Antoine Tenart
Cc: Stefan Chulski, Russell King - ARM Linux, davem, kishon,
gregory.clement, jason, sebastian.hesselbarth, netdev,
linux-kernel, thomas.petazzoni, maxime.chevallier, miquel.raynal,
Nadav Haklai, Yan Markman, mw, linux-arm-kernel
> 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:24 ` Andrew Lunn
0 siblings, 0 replies; 81+ messages in thread
From: Andrew Lunn @ 2018-03-19 13:24 UTC (permalink / raw)
To: Antoine Tenart
Cc: Stefan Chulski, Russell King - ARM Linux, davem, kishon,
gregory.clement, jason, sebastian.hesselbarth, netdev,
linux-kernel, thomas.petazzoni, maxime.chevallier, miquel.raynal,
Nadav Haklai, Yan Markman, mw,
> 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:24 ` Andrew Lunn
0 siblings, 0 replies; 81+ messages in thread
From: Andrew Lunn @ 2018-03-19 13:24 UTC (permalink / raw)
To: linux-arm-kernel
> 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 13:18 ` Russell King - ARM Linux
@ 2018-03-19 13:26 ` Antoine Tenart
-1 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 13:26 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, Andrew Lunn, davem, kishon, gregory.clement,
jason, sebastian.hesselbarth, netdev, linux-kernel,
thomas.petazzoni, maxime.chevallier, miquel.raynal, nadavh,
stefanc, ymarkman, mw, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:26 ` Antoine Tenart
0 siblings, 0 replies; 81+ messages in thread
From: Antoine Tenart @ 2018-03-19 13:26 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
2018-03-19 13:19 ` Stefan Chulski
(?)
@ 2018-03-19 13:42 ` Russell King - ARM Linux
-1 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-19 13:42 UTC (permalink / raw)
To: Stefan Chulski
Cc: Andrew Lunn, Antoine Tenart, davem, kishon, gregory.clement,
jason, sebastian.hesselbarth, netdev, linux-kernel,
thomas.petazzoni, maxime.chevallier, miquel.raynal, Nadav Haklai,
Yan Markman, mw, linux-arm-kernel
On Mon, Mar 19, 2018 at 01:19:24PM +0000, Stefan Chulski wrote:
>
>
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Monday, March 19, 2018 3:08 PM
> > To: Stefan Chulski <stefanc@marvell.com>
> > Cc: Antoine Tenart <antoine.tenart@bootlin.com>; Russell King - ARM Linux
> > <linux@armlinux.org.uk>; davem@davemloft.net; kishon@ti.com;
> > gregory.clement@bootlin.com; jason@lakedaemon.net;
> > sebastian.hesselbarth@gmail.com; netdev@vger.kernel.org; linux-
> > kernel@vger.kernel.org; thomas.petazzoni@bootlin.com;
> > maxime.chevallier@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai
> > <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>;
> > mw@semihalf.com; linux-arm-kernel@lists.infradead.org
> > 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:42 ` Russell King - ARM Linux
0 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-19 13:42 UTC (permalink / raw)
To: Stefan Chulski
Cc: Andrew Lunn, Antoine Tenart, davem, kishon, gregory.clement,
jason, sebastian.hesselbarth, netdev, linux-kernel,
thomas.petazzoni, maxime.chevallier, miquel.raynal, Nadav Haklai,
Yan Markman, mw, linux-arm-kernel@lists.infradead.org
On Mon, Mar 19, 2018 at 01:19:24PM +0000, Stefan Chulski wrote:
>
>
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Monday, March 19, 2018 3:08 PM
> > To: Stefan Chulski <stefanc@marvell.com>
> > Cc: Antoine Tenart <antoine.tenart@bootlin.com>; Russell King - ARM Linux
> > <linux@armlinux.org.uk>; davem@davemloft.net; kishon@ti.com;
> > gregory.clement@bootlin.com; jason@lakedaemon.net;
> > sebastian.hesselbarth@gmail.com; netdev@vger.kernel.org; linux-
> > kernel@vger.kernel.org; thomas.petazzoni@bootlin.com;
> > maxime.chevallier@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai
> > <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>;
> > mw@semihalf.com; linux-arm-kernel@lists.infradead.org
> > 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
^ permalink raw reply [flat|nested] 81+ messages in thread
* [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
@ 2018-03-19 13:42 ` Russell King - ARM Linux
0 siblings, 0 replies; 81+ messages in thread
From: Russell King - ARM Linux @ 2018-03-19 13:42 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 19, 2018 at 01:19:24PM +0000, Stefan Chulski wrote:
>
>
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew at lunn.ch]
> > Sent: Monday, March 19, 2018 3:08 PM
> > To: Stefan Chulski <stefanc@marvell.com>
> > Cc: Antoine Tenart <antoine.tenart@bootlin.com>; Russell King - ARM Linux
> > <linux@armlinux.org.uk>; davem at davemloft.net; kishon at ti.com;
> > gregory.clement at bootlin.com; jason at lakedaemon.net;
> > sebastian.hesselbarth at gmail.com; netdev at vger.kernel.org; linux-
> > kernel at vger.kernel.org; thomas.petazzoni at bootlin.com;
> > maxime.chevallier at bootlin.com; miquel.raynal at bootlin.com; Nadav Haklai
> > <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>;
> > mw at semihalf.com; linux-arm-kernel at lists.infradead.org
> > 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
^ permalink raw reply [flat|nested] 81+ messages in thread
end of thread, other threads:[~2018-03-19 13:42 UTC | newest]
Thread overview: 81+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-16 10:33 [PATCH net-next 00/10] net: mvpp2: phylink conversion Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-16 10:33 ` [PATCH net-next 01/10] net: mvpp2: align the ethtool ops definition Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-16 10:33 ` [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-16 15:53 ` Russell King - ARM Linux
2018-03-16 15:53 ` Russell King - ARM Linux
2018-03-19 8:52 ` Antoine Tenart
2018-03-19 8:52 ` Antoine Tenart
2018-03-19 11:12 ` Russell King - ARM Linux
2018-03-19 11:12 ` Russell King - ARM Linux
2018-03-19 12:52 ` Antoine Tenart
2018-03-19 12:52 ` Antoine Tenart
2018-03-19 12:59 ` Andrew Lunn
2018-03-19 12:59 ` Andrew Lunn
2018-03-19 13:03 ` [EXT] " Stefan Chulski
2018-03-19 13:03 ` Stefan Chulski
2018-03-19 13:03 ` Stefan Chulski
2018-03-19 13:08 ` Andrew Lunn
2018-03-19 13:08 ` Andrew Lunn
2018-03-19 13:08 ` Andrew Lunn
2018-03-19 13:13 ` Antoine Tenart
2018-03-19 13:13 ` Antoine Tenart
2018-03-19 13:13 ` Antoine Tenart
2018-03-19 13:24 ` Andrew Lunn
2018-03-19 13:24 ` Andrew Lunn
2018-03-19 13:24 ` Andrew Lunn
2018-03-19 13:19 ` Stefan Chulski
2018-03-19 13:19 ` Stefan Chulski
2018-03-19 13:19 ` Stefan Chulski
2018-03-19 13:23 ` Andrew Lunn
2018-03-19 13:23 ` Andrew Lunn
2018-03-19 13:23 ` Andrew Lunn
2018-03-19 13:42 ` Russell King - ARM Linux
2018-03-19 13:42 ` Russell King - ARM Linux
2018-03-19 13:42 ` Russell King - ARM Linux
2018-03-19 13:10 ` Antoine Tenart
2018-03-19 13:10 ` Antoine Tenart
2018-03-19 13:18 ` Russell King - ARM Linux
2018-03-19 13:18 ` Russell King - ARM Linux
2018-03-19 13:26 ` Antoine Tenart
2018-03-19 13:26 ` Antoine Tenart
2018-03-19 12:58 ` [EXT] " Stefan Chulski
2018-03-19 12:58 ` Stefan Chulski
2018-03-19 13:01 ` Yan Markman
2018-03-19 13:01 ` Yan Markman
2018-03-19 13:01 ` Yan Markman
2018-03-19 13:05 ` Russell King - ARM Linux
2018-03-19 13:05 ` Russell King - ARM Linux
2018-03-19 13:05 ` Russell King - ARM Linux
2018-03-16 10:33 ` [PATCH net-next 03/10] net: mvpp2: phylink support Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-16 16:03 ` Russell King - ARM Linux
2018-03-16 16:03 ` Russell King - ARM Linux
2018-03-19 8:45 ` Antoine Tenart
2018-03-19 8:45 ` Antoine Tenart
2018-03-16 10:33 ` [PATCH net-next 04/10] phy: add 2.5G SGMII mode to the phy_mode enum Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-19 9:46 ` Kishon Vijay Abraham I
2018-03-19 9:46 ` Kishon Vijay Abraham I
2018-03-19 9:46 ` Kishon Vijay Abraham I
2018-03-16 10:33 ` [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-18 4:42 ` Baruch Siach
2018-03-18 4:42 ` Baruch Siach
2018-03-19 8:44 ` Antoine Tenart
2018-03-19 8:44 ` Antoine Tenart
2018-03-16 10:33 ` [PATCH net-next 06/10] net: mvpp2: 1000baseX support Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-16 10:33 ` [PATCH net-next 07/10] net: mvpp2: 2500baseX support Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-16 10:33 ` [PATCH net-next 08/10] arm64: dts: marvell: 7040-db: set the 10G interface management to in-band Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-16 10:33 ` [PATCH net-next 09/10] arm64: dts: marvell: 8040-db: set the 10G interfaces " Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
2018-03-16 10:33 ` [PATCH net-next 10/10] arm64: dts: marvell: mcbin: enable the fourth network interface Antoine Tenart
2018-03-16 10:33 ` Antoine Tenart
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.