QCA8084 is four-port PHY with maximum link capability 2.5G,
which supports the interface mode qusgmii and sgmii mode,
there are two PCSs available to connected with ethernet port.
QCA8084 can work in switch mode or PHY mode.
For switch mode, both PCS0 and PCS1 work on sgmii mode.
For PHY mode, PCS1 works on qusgmii mode, the last port
(the fourth port) works on sgmii mode.
Besides this PHY driver patches, the PCS driver is also needed
to bring up the qca8084 device, which mainly configurs PCS
and clocks.
Changes in v3:
* pick the two patches to introduce the interface mode
10g-qxgmii from Vladimir Oltean([email protected]).
* add the function phydev_id_is_qca808x to identify the
PHY qca8081 and qca8084.
* update the interface mode name PHY_INTERFACE_MODE_QUSGMII
to PHY_INTERFACE_MODE_10G_QXGMII.
Changes in v4:
* remove the following patch:
<net: phylink: move phylink_pcs_neg_mode() to phylink.c>.
* split out 10g_qxgmii change of ethernet-controller.yaml.
Changes in v5:
* update the author of the patch below.
<introduce core support for phy-mode = "10g-qxgmii">.
Luo Jie (4):
net: phy: at803x: add QCA8084 ethernet phy support
net: phy: at803x: add the function phydev_id_is_qca808x
net: phy: at803x: Add qca8084_config_init function
net: phy: qca8084: add qca8084_link_change_notify
Vladimir Oltean (2):
net: phy: introduce core support for phy-mode = "10g-qxgmii"
dt-bindings: net: ethernet-controller: add 10g-qxgmii mode
.../bindings/net/ethernet-controller.yaml | 1 +
Documentation/networking/phy.rst | 6 +
drivers/net/phy/at803x.c | 130 +++++++++++++++++-
drivers/net/phy/phy-core.c | 1 +
drivers/net/phy/phylink.c | 11 +-
include/linux/phy.h | 4 +
include/linux/phylink.h | 2 +
7 files changed, 147 insertions(+), 8 deletions(-)
base-commit: eff99d8edbed7918317331ebd1e365d8e955d65e
--
2.42.0
From: Vladimir Oltean <[email protected]>
10G-QXGMII is a MAC-to-PHY interface defined by the USXGMII multiport
specification. It uses the same signaling as USXGMII, but it multiplexes
4 ports over the link, resulting in a maximum speed of 2.5G per port.
Some in-tree SoCs like the NXP LS1028A use "usxgmii" when they mean
either the single-port USXGMII or the quad-port 10G-QXGMII variant, and
they could get away just fine with that thus far. But there is a need to
distinguish between the 2 as far as SerDes drivers are concerned.
Signed-off-by: Vladimir Oltean <[email protected]>
Signed-off-by: Luo Jie <[email protected]>
---
Documentation/networking/phy.rst | 6 ++++++
drivers/net/phy/phy-core.c | 1 +
drivers/net/phy/phylink.c | 11 +++++++++--
include/linux/phy.h | 4 ++++
include/linux/phylink.h | 2 ++
5 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst
index 1283240d7620..f64641417c54 100644
--- a/Documentation/networking/phy.rst
+++ b/Documentation/networking/phy.rst
@@ -327,6 +327,12 @@ Some of the interface modes are described below:
This is the Penta SGMII mode, it is similar to QSGMII but it combines 5
SGMII lines into a single link compared to 4 on QSGMII.
+``PHY_INTERFACE_MODE_10G_QXGMII``
+ Represents the 10G-QXGMII PHY-MAC interface as defined by the Cisco USXGMII
+ Multiport Copper Interface document. It supports 4 ports over a 10.3125 GHz
+ SerDes lane, each port having speeds of 2.5G / 1G / 100M / 10M achieved
+ through symbol replication. The PCS expects the standard USXGMII code word.
+
Pause frames / flow control
===========================
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index 966c93cbe616..1cd58723d6d0 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -141,6 +141,7 @@ int phy_interface_num_ports(phy_interface_t interface)
return 1;
case PHY_INTERFACE_MODE_QSGMII:
case PHY_INTERFACE_MODE_QUSGMII:
+ case PHY_INTERFACE_MODE_10G_QXGMII:
return 4;
case PHY_INTERFACE_MODE_PSGMII:
return 5;
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 25c19496a336..491481568754 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -218,6 +218,7 @@ static int phylink_interface_max_speed(phy_interface_t interface)
return SPEED_1000;
case PHY_INTERFACE_MODE_2500BASEX:
+ case PHY_INTERFACE_MODE_10G_QXGMII:
return SPEED_2500;
case PHY_INTERFACE_MODE_5GBASER:
@@ -487,7 +488,11 @@ static unsigned long phylink_get_capabilities(phy_interface_t interface,
switch (interface) {
case PHY_INTERFACE_MODE_USXGMII:
- caps |= MAC_10000FD | MAC_5000FD | MAC_2500FD;
+ caps |= MAC_10000FD | MAC_5000FD;
+ fallthrough;
+
+ case PHY_INTERFACE_MODE_10G_QXGMII:
+ caps |= MAC_2500FD;
fallthrough;
case PHY_INTERFACE_MODE_RGMII_TXID:
@@ -907,6 +912,7 @@ static int phylink_parse_mode(struct phylink *pl,
phylink_set(pl->supported, 25000baseSR_Full);
fallthrough;
case PHY_INTERFACE_MODE_USXGMII:
+ case PHY_INTERFACE_MODE_10G_QXGMII:
case PHY_INTERFACE_MODE_10GKR:
case PHY_INTERFACE_MODE_10GBASER:
phylink_set(pl->supported, 10baseT_Half);
@@ -1779,7 +1785,8 @@ static int phylink_bringup_phy(struct phylink *pl, struct phy_device *phy,
if (phy->is_c45 && config.rate_matching == RATE_MATCH_NONE &&
interface != PHY_INTERFACE_MODE_RXAUI &&
interface != PHY_INTERFACE_MODE_XAUI &&
- interface != PHY_INTERFACE_MODE_USXGMII)
+ interface != PHY_INTERFACE_MODE_USXGMII &&
+ interface != PHY_INTERFACE_MODE_10G_QXGMII)
config.interface = PHY_INTERFACE_MODE_NA;
else
config.interface = interface;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 3cc52826f18e..e0af0378e2a1 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -125,6 +125,7 @@ extern const int phy_10gbit_features_array[1];
* @PHY_INTERFACE_MODE_10GKR: 10GBASE-KR - with Clause 73 AN
* @PHY_INTERFACE_MODE_QUSGMII: Quad Universal SGMII
* @PHY_INTERFACE_MODE_1000BASEKX: 1000Base-KX - with Clause 73 AN
+ * @PHY_INTERFACE_MODE_10G_QXGMII: 10G-QXGMII - 4 ports over 10G USXGMII
* @PHY_INTERFACE_MODE_MAX: Book keeping
*
* Describes the interface between the MAC and PHY.
@@ -165,6 +166,7 @@ typedef enum {
PHY_INTERFACE_MODE_10GKR,
PHY_INTERFACE_MODE_QUSGMII,
PHY_INTERFACE_MODE_1000BASEKX,
+ PHY_INTERFACE_MODE_10G_QXGMII,
PHY_INTERFACE_MODE_MAX,
} phy_interface_t;
@@ -286,6 +288,8 @@ static inline const char *phy_modes(phy_interface_t interface)
return "100base-x";
case PHY_INTERFACE_MODE_QUSGMII:
return "qusgmii";
+ case PHY_INTERFACE_MODE_10G_QXGMII:
+ return "10g-qxgmii";
default:
return "unknown";
}
diff --git a/include/linux/phylink.h b/include/linux/phylink.h
index 875439ab45de..92bd2726cc8a 100644
--- a/include/linux/phylink.h
+++ b/include/linux/phylink.h
@@ -128,6 +128,7 @@ static inline unsigned int phylink_pcs_neg_mode(unsigned int mode,
case PHY_INTERFACE_MODE_QSGMII:
case PHY_INTERFACE_MODE_QUSGMII:
case PHY_INTERFACE_MODE_USXGMII:
+ case PHY_INTERFACE_MODE_10G_QXGMII:
/* These protocols are designed for use with a PHY which
* communicates its negotiation result back to the MAC via
* inband communication. Note: there exist PHYs that run
@@ -680,6 +681,7 @@ static inline int phylink_get_link_timer_ns(phy_interface_t interface)
case PHY_INTERFACE_MODE_SGMII:
case PHY_INTERFACE_MODE_QSGMII:
case PHY_INTERFACE_MODE_USXGMII:
+ case PHY_INTERFACE_MODE_10G_QXGMII:
return 1600000;
case PHY_INTERFACE_MODE_1000BASEX:
--
2.42.0
From: Vladimir Oltean <[email protected]>
Add the new interface mode 10g-qxgmii, which is similar to
usxgmii but extend to 4 channels to support maximum of 4
ports with the link speed 10M/100M/1G/2.5G.
Signed-off-by: Vladimir Oltean <[email protected]>
Signed-off-by: Luo Jie <[email protected]>
Acked-by: Conor Dooley <[email protected]>
---
This patch is separated from Vladimir Oltean's previous patch
<net: phy: introduce core support for phy-mode = "10g-qxgmii">.
Documentation/devicetree/bindings/net/ethernet-controller.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
index d14d123ad7a0..0ef6103c5fd8 100644
--- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -104,6 +104,7 @@ properties:
- usxgmii
- 10gbase-r
- 25gbase-r
+ - 10g-qxgmii
phy-mode:
$ref: "#/properties/phy-connection-type"
--
2.42.0
Add qca8084 PHY support, which is four-port PHY with maximum
link capability 2.5G, the features of each port is almost same
as QCA8081 and slave seed config is not needed.
Three kind of interface modes supported by qca8084.
PHY_INTERFACE_MODE_10G_QXGMII, PHY_INTERFACE_MODE_2500BASEX and
PHY_INTERFACE_MODE_SGMII.
The PCS(serdes) and clock are also needed to be configured to
bringup qca8084 PHY, which will be added in the pcs driver.
The additional CDT configurations used for qca8084.
Signed-off-by: Luo Jie <[email protected]>
---
drivers/net/phy/at803x.c | 48 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 37fb033e1c29..471d5c13d76d 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -176,6 +176,7 @@
#define AT8030_PHY_ID_MASK 0xffffffef
#define QCA8081_PHY_ID 0x004dd101
+#define QCA8084_PHY_ID 0x004dd180
#define QCA8327_A_PHY_ID 0x004dd033
#define QCA8327_B_PHY_ID 0x004dd034
@@ -1760,6 +1761,9 @@ static bool qca808x_is_prefer_master(struct phy_device *phydev)
static bool qca808x_has_fast_retrain_or_slave_seed(struct phy_device *phydev)
{
+ if (phydev_id_compare(phydev, QCA8084_PHY_ID))
+ return false;
+
return linkmode_test_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, phydev->supported);
}
@@ -1824,6 +1828,21 @@ static int qca808x_read_status(struct phy_device *phydev)
return ret;
if (phydev->link) {
+ /* There are two PCSs available for QCA8084, which support the following
+ * interface modes.
+ *
+ * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all available 4 ports,
+ * which is for all link speeds.
+ *
+ * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the fourth port,
+ * which is only for the link speed 2500M same as QCA8081.
+ *
+ * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth port,
+ * which is for the link speed 10M, 100M and 1000M same as QCA8081.
+ */
+ if (phydev->interface == PHY_INTERFACE_MODE_10G_QXGMII)
+ return 0;
+
if (phydev->speed == SPEED_2500)
phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
else
@@ -1958,6 +1977,14 @@ static int qca808x_cable_test_start(struct phy_device *phydev)
phy_write_mmd(phydev, MDIO_MMD_PCS, 0x807a, 0xc060);
phy_write_mmd(phydev, MDIO_MMD_PCS, 0x807e, 0xb060);
+ if (phydev_id_compare(phydev, QCA8084_PHY_ID)) {
+ /* Adjust the positive and negative pulse thereshold of CDT */
+ phy_write_mmd(phydev, MDIO_MMD_PCS, 0x8075, 0xa060);
+
+ /* Disable the near echo bypass */
+ phy_modify_mmd(phydev, MDIO_MMD_PCS, 0x807f, BIT(15), 0);
+ }
+
return 0;
}
@@ -2227,6 +2254,26 @@ static struct phy_driver at803x_driver[] = {
.cable_test_start = qca808x_cable_test_start,
.cable_test_get_status = qca808x_cable_test_get_status,
.link_change_notify = qca808x_link_change_notify,
+}, {
+ /* Qualcomm QCA8084 */
+ PHY_ID_MATCH_MODEL(QCA8084_PHY_ID),
+ .name = "Qualcomm QCA8084",
+ .flags = PHY_POLL_CABLE_TEST,
+ .probe = at803x_probe,
+ .config_intr = at803x_config_intr,
+ .handle_interrupt = at803x_handle_interrupt,
+ .get_tunable = at803x_get_tunable,
+ .set_tunable = at803x_set_tunable,
+ .set_wol = at803x_set_wol,
+ .get_wol = at803x_get_wol,
+ .get_features = qca808x_get_features,
+ .config_aneg = at803x_config_aneg,
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ .read_status = qca808x_read_status,
+ .soft_reset = qca808x_soft_reset,
+ .cable_test_start = qca808x_cable_test_start,
+ .cable_test_get_status = qca808x_cable_test_get_status,
}, };
module_phy_driver(at803x_driver);
@@ -2242,6 +2289,7 @@ static struct mdio_device_id __maybe_unused atheros_tbl[] = {
{ PHY_ID_MATCH_EXACT(QCA8327_B_PHY_ID) },
{ PHY_ID_MATCH_EXACT(QCA9561_PHY_ID) },
{ PHY_ID_MATCH_EXACT(QCA8081_PHY_ID) },
+ { PHY_ID_MATCH_MODEL(QCA8084_PHY_ID) },
{ }
};
--
2.42.0
The function phydev_id_is_qca808x is applicable to the
PHY qca8081 and qca8084.
Signed-off-by: Luo Jie <[email protected]>
---
drivers/net/phy/at803x.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 471d5c13d76d..f56202f5944d 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -1165,6 +1165,12 @@ static void at803x_link_change_notify(struct phy_device *phydev)
}
}
+static inline bool phydev_id_is_qca808x(struct phy_device *phydev)
+{
+ return phydev_id_compare(phydev, QCA8081_PHY_ID) ||
+ phydev_id_compare(phydev, QCA8084_PHY_ID);
+}
+
static int at803x_read_specific_status(struct phy_device *phydev)
{
int ss;
@@ -1184,8 +1190,8 @@ static int at803x_read_specific_status(struct phy_device *phydev)
if (sfc < 0)
return sfc;
- /* qca8081 takes the different bits for speed value from at803x */
- if (phydev->drv->phy_id == QCA8081_PHY_ID)
+ /* qca808x takes the different bits for speed value from at803x */
+ if (phydev_id_is_qca808x(phydev))
speed = FIELD_GET(QCA808X_SS_SPEED_MASK, ss);
else
speed = FIELD_GET(AT803X_SS_SPEED_MASK, ss);
@@ -1316,7 +1322,7 @@ static int at803x_config_aneg(struct phy_device *phydev)
*/
ret = 0;
- if (phydev->drv->phy_id == QCA8081_PHY_ID) {
+ if (phydev_id_is_qca808x(phydev)) {
int phy_ctrl = 0;
/* The reg MII_BMCR also needs to be configured for force mode, the
@@ -1470,8 +1476,8 @@ static int at803x_cdt_start(struct phy_device *phydev, int pair)
{
u16 cdt;
- /* qca8081 takes the different bit 15 to enable CDT test */
- if (phydev->drv->phy_id == QCA8081_PHY_ID)
+ /* qca808x takes the different bit 15 to enable CDT test */
+ if (phydev_id_is_qca808x(phydev))
cdt = QCA808X_CDT_ENABLE_TEST |
QCA808X_CDT_LENGTH_UNIT |
QCA808X_CDT_INTER_CHECK_DIS;
@@ -1487,7 +1493,7 @@ static int at803x_cdt_wait_for_completion(struct phy_device *phydev)
int val, ret;
u16 cdt_en;
- if (phydev->drv->phy_id == QCA8081_PHY_ID)
+ if (phydev_id_is_qca808x(phydev))
cdt_en = QCA808X_CDT_ENABLE_TEST;
else
cdt_en = AT803X_CDT_ENABLE_TEST;
--
2.42.0
Configure MSE detect threshold and ADC clock edge invert.
Signed-off-by: Luo Jie <[email protected]>
---
drivers/net/phy/at803x.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index f56202f5944d..06a068ca5539 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -280,6 +280,15 @@
#define QCA8081_PHY_SERDES_MMD1_FIFO_CTRL 0x9072
#define QCA8081_PHY_FIFO_RSTN BIT(11)
+/* QCA8084 ADC clock edge */
+#define QCA8084_ADC_CLK_SEL 0x8b80
+#define QCA8084_ADC_CLK_SEL_ACLK GENMASK(7, 4)
+#define QCA8084_ADC_CLK_SEL_ACLK_FALL 0xf
+#define QCA8084_ADC_CLK_SEL_ACLK_RISE 0x0
+
+#define QCA8084_MSE_THRESHOLD 0x800a
+#define QCA8084_MSE_THRESHOLD_2P5G_VAL 0x51c6
+
MODULE_DESCRIPTION("Qualcomm Atheros AR803x and QCA808X PHY driver");
MODULE_AUTHOR("Matus Ujhelyi");
MODULE_LICENSE("GPL");
@@ -2083,6 +2092,23 @@ static void qca808x_link_change_notify(struct phy_device *phydev)
QCA8081_PHY_FIFO_RSTN, phydev->link ? QCA8081_PHY_FIFO_RSTN : 0);
}
+static int qca8084_config_init(struct phy_device *phydev)
+{
+ int ret;
+
+ /* Invert ADC clock edge */
+ ret = at803x_debug_reg_mask(phydev, QCA8084_ADC_CLK_SEL,
+ QCA8084_ADC_CLK_SEL_ACLK,
+ FIELD_PREP(QCA8084_ADC_CLK_SEL_ACLK,
+ QCA8084_ADC_CLK_SEL_ACLK_FALL));
+ if (ret < 0)
+ return ret;
+
+ /* Adjust MSE threshold value to avoid link issue with some link partner */
+ return phy_write_mmd(phydev, MDIO_MMD_PMAPMD,
+ QCA8084_MSE_THRESHOLD, QCA8084_MSE_THRESHOLD_2P5G_VAL);
+}
+
static struct phy_driver at803x_driver[] = {
{
/* Qualcomm Atheros AR8035 */
@@ -2280,6 +2306,7 @@ static struct phy_driver at803x_driver[] = {
.soft_reset = qca808x_soft_reset,
.cable_test_start = qca808x_cable_test_start,
.cable_test_get_status = qca808x_cable_test_get_status,
+ .config_init = qca8084_config_init,
}, };
module_phy_driver(at803x_driver);
--
2.42.0
When the link is changed, qca8084 needs to do the fifo reset and
adjust the IPG level for the qusgmii link speed 1000M.
Signed-off-by: Luo Jie <[email protected]>
---
drivers/net/phy/at803x.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 06a068ca5539..7267ce858937 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -289,6 +289,13 @@
#define QCA8084_MSE_THRESHOLD 0x800a
#define QCA8084_MSE_THRESHOLD_2P5G_VAL 0x51c6
+#define QCA8084_FIFO_CONTROL 0x19
+#define QCA8084_FIFO_MAC_2_PHY BIT(1)
+#define QCA8084_FIFO_PHY_2_MAC BIT(0)
+
+#define QCA8084_MMD7_IPG_OP 0x901d
+#define QCA8084_IPG_10_TO_11_EN BIT(0)
+
MODULE_DESCRIPTION("Qualcomm Atheros AR803x and QCA808X PHY driver");
MODULE_AUTHOR("Matus Ujhelyi");
MODULE_LICENSE("GPL");
@@ -2109,6 +2116,35 @@ static int qca8084_config_init(struct phy_device *phydev)
QCA8084_MSE_THRESHOLD, QCA8084_MSE_THRESHOLD_2P5G_VAL);
}
+static void qca8084_link_change_notify(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = phy_modify(phydev, QCA8084_FIFO_CONTROL,
+ QCA8084_FIFO_MAC_2_PHY | QCA8084_FIFO_PHY_2_MAC,
+ 0);
+ if (ret)
+ return;
+
+ /* If the PHY works on PHY_INTERFACE_MODE_10G_QXGMII mode, the fifo needs to
+ * be kept as reset state in link down status.
+ */
+ if (phydev->interface != PHY_INTERFACE_MODE_10G_QXGMII || phydev->link) {
+ msleep(50);
+ ret = phy_modify(phydev, QCA8084_FIFO_CONTROL,
+ QCA8084_FIFO_MAC_2_PHY | QCA8084_FIFO_PHY_2_MAC,
+ QCA8084_FIFO_MAC_2_PHY | QCA8084_FIFO_PHY_2_MAC);
+ if (ret)
+ return;
+ }
+
+ /* Enable IPG 10 to 11 tuning on link speed 1000M of QUSGMII mode. */
+ if (phydev->interface == PHY_INTERFACE_MODE_10G_QXGMII)
+ phy_modify_mmd(phydev, MDIO_MMD_AN, QCA8084_MMD7_IPG_OP,
+ QCA8084_IPG_10_TO_11_EN,
+ phydev->speed == SPEED_1000 ? QCA8084_IPG_10_TO_11_EN : 0);
+}
+
static struct phy_driver at803x_driver[] = {
{
/* Qualcomm Atheros AR8035 */
@@ -2307,6 +2343,7 @@ static struct phy_driver at803x_driver[] = {
.cable_test_start = qca808x_cable_test_start,
.cable_test_get_status = qca808x_cable_test_get_status,
.config_init = qca8084_config_init,
+ .link_change_notify = qca8084_link_change_notify,
}, };
module_phy_driver(at803x_driver);
--
2.42.0
On Sat, Nov 18, 2023 at 02:27:51PM +0800, Luo Jie wrote:
> Add qca8084 PHY support, which is four-port PHY with maximum
> link capability 2.5G, the features of each port is almost same
> as QCA8081 and slave seed config is not needed.
>
> Three kind of interface modes supported by qca8084.
> PHY_INTERFACE_MODE_10G_QXGMII, PHY_INTERFACE_MODE_2500BASEX and
> PHY_INTERFACE_MODE_SGMII.
Sorry for joining the conversation late.
I'm trying to get my head around QXGMII. Let me describe what i think
is happening, and then you can correct me....
You have 4 MACs, probably in a switch. The MII interfaces from these
MACs go into a multiplexer, and out comes QXGMII? You then have a
SERDES interface out of the switch and into the PHY package. Inside
the PHY package there is a demultiplexor, giving you four MII
interfaces, one to each PHY in the package.
If you have the PHY SERDES running in 2500BaseX, you have a single
MAC, no mux/demux, and only one PHY is used? The other three are idle.
Same from SGMII?
So the interface mode QXGMII is a property of the package. It is not
really a property of one PHY. Having one PHY using QXGMII and another
SGMII does not work?
Andrew
On Sat, Nov 18, 2023 at 04:51:42PM +0100, Andrew Lunn wrote:
> On Sat, Nov 18, 2023 at 02:27:51PM +0800, Luo Jie wrote:
> > Add qca8084 PHY support, which is four-port PHY with maximum
> > link capability 2.5G, the features of each port is almost same
> > as QCA8081 and slave seed config is not needed.
> >
> > Three kind of interface modes supported by qca8084.
> > PHY_INTERFACE_MODE_10G_QXGMII, PHY_INTERFACE_MODE_2500BASEX and
> > PHY_INTERFACE_MODE_SGMII.
>
> Sorry for joining the conversation late.
>
> I'm trying to get my head around QXGMII. Let me describe what i think
> is happening, and then you can correct me....
>
> You have 4 MACs, probably in a switch. The MII interfaces from these
> MACs go into a multiplexer, and out comes QXGMII? You then have a
> SERDES interface out of the switch and into the PHY package. Inside
> the PHY package there is a demultiplexor, giving you four MII
> interfaces, one to each PHY in the package.
>
> If you have the PHY SERDES running in 2500BaseX, you have a single
> MAC, no mux/demux, and only one PHY is used? The other three are idle.
> Same from SGMII?
>
> So the interface mode QXGMII is a property of the package. It is not
> really a property of one PHY. Having one PHY using QXGMII and another
> SGMII does not work?
10G_QXGMII is defined in the Cisco USXGMII multi-port document as one
of several possibilities for a USXGMII-M link. The Cisco document can
be a little confusing beause it states that 10G_QXGMII supports 10M,
100M, 1G and 2.5G, and then only talks about a 10G and 100M/1G MAC.
For 10G_QXGMII, there are 4 MAC interfaces. These are connected to a
rate "adaption" through symbol replication block, and then on to a
clause 49 PCS block.
There is then a port MUX and framing block, followed by the PMA
serdes which communicates with the remote end over a single pair of
transmit/receive serdes lines.
Each interface also has its own clause 37 autoneg block.
So, for an interface to operate in SGMII mode, it would have to be
muxed to a different path before being presented to the USXGMII-M
block since each interface does not have its own external data lane
- thus that's out of scope of USXGMII-M as documented by Cisco.
Hope this helps.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
> 10G_QXGMII is defined in the Cisco USXGMII multi-port document as one
> of several possibilities for a USXGMII-M link. The Cisco document can
> be a little confusing beause it states that 10G_QXGMII supports 10M,
> 100M, 1G and 2.5G, and then only talks about a 10G and 100M/1G MAC.
>
> For 10G_QXGMII, there are 4 MAC interfaces. These are connected to a
> rate "adaption" through symbol replication block, and then on to a
> clause 49 PCS block.
>
> There is then a port MUX and framing block, followed by the PMA
> serdes which communicates with the remote end over a single pair of
> transmit/receive serdes lines.
>
> Each interface also has its own clause 37 autoneg block.
>
> So, for an interface to operate in SGMII mode, it would have to be
> muxed to a different path before being presented to the USXGMII-M
> block since each interface does not have its own external data lane
> - thus that's out of scope of USXGMII-M as documented by Cisco.
Hi Russell
I think it helps.
Where i'm having trouble is deciding if this is actually an interface
mode. Interface mode is a per PHY property. Where as it seems
10G_QXGMII is a property of the USXGMII-M link? Should we be
representing the package with 4 PHYs in it, and specify the package
has a PMA which is using 10G_QXGMII over USXGMII-M? The PHY interface
mode is then internal? Its just the link between the PHY and the MUX?
By saying the interface mode is 10G_QXGMII and not describing the PMA
mode, are we setting ourselves up for problems in the future? Could
there be a PMA interface which could carry different PHY interface
modes?
If we decide we do want to use 10G_QXGMII as an interface made, i
think the driver should be doing some validation. If asked to do
anything else, it should return -EINVAL.
And i don't yet understand how it can also do 1000BaseX and 2500BaseX
and SGMII?
Andrew
On Sat, 18 Nov 2023 14:27:52 +0800 Luo Jie wrote:
> +static inline bool phydev_id_is_qca808x(struct phy_device *phydev)
Please drop the "inline" keyword. The compiler will decide what's best.
On Sat, 18 Nov 2023 14:27:51 +0800 Luo Jie wrote:
> + /* There are two PCSs available for QCA8084, which support the following
> + * interface modes.
> + *
> + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all available 4 ports,
> + * which is for all link speeds.
> + *
> + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the fourth port,
> + * which is only for the link speed 2500M same as QCA8081.
> + *
> + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth port,
> + * which is for the link speed 10M, 100M and 1000M same as QCA8081.
Wrap the comments please.
Please use checkpatch with --max-line-length=80
On 11/19/2023 4:19 AM, Andrew Lunn wrote:
>> 10G_QXGMII is defined in the Cisco USXGMII multi-port document as one
>> of several possibilities for a USXGMII-M link. The Cisco document can
>> be a little confusing beause it states that 10G_QXGMII supports 10M,
>> 100M, 1G and 2.5G, and then only talks about a 10G and 100M/1G MAC.
>>
>> For 10G_QXGMII, there are 4 MAC interfaces. These are connected to a
>> rate "adaption" through symbol replication block, and then on to a
>> clause 49 PCS block.
>>
>> There is then a port MUX and framing block, followed by the PMA
>> serdes which communicates with the remote end over a single pair of
>> transmit/receive serdes lines.
>>
>> Each interface also has its own clause 37 autoneg block.
>>
>> So, for an interface to operate in SGMII mode, it would have to be
>> muxed to a different path before being presented to the USXGMII-M
>> block since each interface does not have its own external data lane
>> - thus that's out of scope of USXGMII-M as documented by Cisco.
>
> Hi Russell
>
> I think it helps.
>
> Where i'm having trouble is deciding if this is actually an interface
> mode. Interface mode is a per PHY property. Where as it seems
> 10G_QXGMII is a property of the USXGMII-M link? Should we be
> representing the package with 4 PHYs in it, and specify the package
> has a PMA which is using 10G_QXGMII over USXGMII-M? The PHY interface
> mode is then internal? Its just the link between the PHY and the MUX?
>
> By saying the interface mode is 10G_QXGMII and not describing the PMA
> mode, are we setting ourselves up for problems in the future? Could
> there be a PMA interface which could carry different PHY interface
> modes?
>
> If we decide we do want to use 10G_QXGMII as an interface made, i
> think the driver should be doing some validation. If asked to do
> anything else, it should return -EINVAL.
>
> And i don't yet understand how it can also do 1000BaseX and 2500BaseX
> and SGMII?
>
> Andrew
Hi Andrew,
The interface mode 10G_QXGMII is a type of USXGMII-M, the other modes
such as 20G-QXGMII, 20G-OXGMII...
As for the interface mode 10G-QXGMII, there is a multiplexer for 4 PHYs,
then do 66bit/68bit encode in xpcs and pass to PMA, the link topology:
quad PHY --- multiplexer ---XPCS --- PMA.
the 10G-QXGMII interface block includes multiplexer, XPCS and PMA.
when the PHY works on SGMII mode, then there is no xpcs, the only fourth
PHY of qca8084 can work on SGMII mode, the link topology:
the fourth PHY --- PCS --- PMA, the SGMII block includes PCS and PMA.
Either 10G-QXGMII or SGMII block of qca8084 connects with the interface
block(10G-QXGMII or SGMII) in MAC side.
Here is a problem as Russell mentioned earlier, we need to know which
PHY device is changing the link status when the 10G-QXGMII mode is used,
since there are 4 PHYs, when one of them has the link change, there is
no PHY device information passed to the PHYLINK, so the PCS driver don't
which PHY is changing link status and 10G-QXGMII mode don't know which
channel(mapped to PHY) should be configured.
would we add a field such as (int channel) in the struct phy_device?
so we can pass this information to PCS driver when the PHY link changed.
Thanks,
On 11/19/2023 8:22 AM, Jakub Kicinski wrote:
> On Sat, 18 Nov 2023 14:27:52 +0800 Luo Jie wrote:
>> +static inline bool phydev_id_is_qca808x(struct phy_device *phydev)
>
> Please drop the "inline" keyword. The compiler will decide what's best.
OK, will remove the "inline" in the next patch.
On 11/19/2023 8:23 AM, Jakub Kicinski wrote:
> On Sat, 18 Nov 2023 14:27:51 +0800 Luo Jie wrote:
>> + /* There are two PCSs available for QCA8084, which support the following
>> + * interface modes.
>> + *
>> + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all available 4 ports,
>> + * which is for all link speeds.
>> + *
>> + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the fourth port,
>> + * which is only for the link speed 2500M same as QCA8081.
>> + *
>> + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth port,
>> + * which is for the link speed 10M, 100M and 1000M same as QCA8081.
>
> Wrap the comments please.
>
> Please use checkpatch with --max-line-length=80
Thanks Jakub, i will add this option for the patch check.
On Mon, Nov 20, 2023 at 04:49:59PM +0800, Jie Luo wrote:
>
>
> On 11/19/2023 4:19 AM, Andrew Lunn wrote:
> > > 10G_QXGMII is defined in the Cisco USXGMII multi-port document as one
> > > of several possibilities for a USXGMII-M link. The Cisco document can
> > > be a little confusing beause it states that 10G_QXGMII supports 10M,
> > > 100M, 1G and 2.5G, and then only talks about a 10G and 100M/1G MAC.
> > >
> > > For 10G_QXGMII, there are 4 MAC interfaces. These are connected to a
> > > rate "adaption" through symbol replication block, and then on to a
> > > clause 49 PCS block.
> > >
> > > There is then a port MUX and framing block, followed by the PMA
> > > serdes which communicates with the remote end over a single pair of
> > > transmit/receive serdes lines.
> > >
> > > Each interface also has its own clause 37 autoneg block.
> > >
> > > So, for an interface to operate in SGMII mode, it would have to be
> > > muxed to a different path before being presented to the USXGMII-M
> > > block since each interface does not have its own external data lane
> > > - thus that's out of scope of USXGMII-M as documented by Cisco.
> >
> > Hi Russell
> >
> > I think it helps.
> >
> > Where i'm having trouble is deciding if this is actually an interface
> > mode. Interface mode is a per PHY property. Where as it seems
> > 10G_QXGMII is a property of the USXGMII-M link? Should we be
> > representing the package with 4 PHYs in it, and specify the package
> > has a PMA which is using 10G_QXGMII over USXGMII-M? The PHY interface
> > mode is then internal? Its just the link between the PHY and the MUX?
> >
> > By saying the interface mode is 10G_QXGMII and not describing the PMA
> > mode, are we setting ourselves up for problems in the future? Could
> > there be a PMA interface which could carry different PHY interface
> > modes?
> >
> > If we decide we do want to use 10G_QXGMII as an interface made, i
> > think the driver should be doing some validation. If asked to do
> > anything else, it should return -EINVAL.
> >
> > And i don't yet understand how it can also do 1000BaseX and 2500BaseX
> > and SGMII?
> >
> > Andrew
>
> Hi Andrew,
> The interface mode 10G_QXGMII is a type of USXGMII-M, the other modes
> such as 20G-QXGMII, 20G-OXGMII...
>
> As for the interface mode 10G-QXGMII, there is a multiplexer for 4 PHYs,
> then do 66bit/68bit encode in xpcs and pass to PMA, the link topology:
> quad PHY --- multiplexer ---XPCS --- PMA.
> the 10G-QXGMII interface block includes multiplexer, XPCS and PMA.
Note that phylink_pcs does *not* cover any PCS on the PHY device side
of the link. It only covers a PCS on the MAC side.
> Here is a problem as Russell mentioned earlier, we need to know which PHY
> device is changing the link status when the 10G-QXGMII mode is used,
> since there are 4 PHYs, when one of them has the link change, there is no
> PHY device information passed to the PHYLINK, so the PCS driver don't
> which PHY is changing link status and 10G-QXGMII mode don't know which
> channel(mapped to PHY) should be configured.
>
> would we add a field such as (int channel) in the struct phy_device?
> so we can pass this information to PCS driver when the PHY link changed.
Nothing in phylink nor phylib is setup to deal with "channels" within
a PHY. The model assumes that a network interface consists of exactly
one MAC associated with one active PHY.
As there are 4 PHYs, phylib will expect there to be four PHY devices,
and there will be expected to be four phylink instances.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
> Hi Andrew,
> The interface mode 10G_QXGMII is a type of USXGMII-M, the other modes
> such as 20G-QXGMII, 20G-OXGMII...
>
> As for the interface mode 10G-QXGMII, there is a multiplexer for 4 PHYs,
> then do 66bit/68bit encode in xpcs and pass to PMA, the link topology:
> quad PHY --- multiplexer ---XPCS --- PMA.
> the 10G-QXGMII interface block includes multiplexer, XPCS and PMA.
>
> when the PHY works on SGMII mode, then there is no xpcs, the only fourth
> PHY of qca8084 can work on SGMII mode, the link topology:
> the fourth PHY --- PCS --- PMA, the SGMII block includes PCS and PMA.
What i missed is that you have two different PMA blocks. PHY4 can be
muxed to either the QXGMII PMA or the 2500BaseX PMA. This is not clear
in the commit message, and i think why you are getting questions about
how 2500BaseX can work over QXGMII. Please expand you commit message
to explain the architecture in more detail.
So, next question. How do you control what PMA PHY4 is connected to?
Is this going to be based on interface mode? QXGMII it is configured
to use the QXGMII PMA? SGMII, 1000BaseX, and 2500BaseX it is
configured to the other PMA?
> Here is a problem as Russell mentioned earlier, we need to know which PHY
> device is changing the link status when the 10G-QXGMII mode is used,
> since there are 4 PHYs, when one of them has the link change, there is no
> PHY device information passed to the PHYLINK, so the PCS driver don't
> which PHY is changing link status and 10G-QXGMII mode don't know which
> channel(mapped to PHY) should be configured.
This is the first time QXGMII has been seen in mainline, so its good
to explain the background.
Are you saying there is a USXGMII-M level link change status? The link
between the SoC and the PHY package is up/down? If it is down, all
four MAC-PHY links are down. If it is up, it is possible to carry
frames between the SoC and the PHY package, but maybe the PHYs
themselves are down?
Withing the four multiplex streams, is there a per stream link change
indication?
Andrew
On Mon, Nov 20, 2023 at 04:34:55PM +0100, Andrew Lunn wrote:
> Are you saying there is a USXGMII-M level link change status? The link
> between the SoC and the PHY package is up/down? If it is down, all
> four MAC-PHY links are down. If it is up, it is possible to carry
> frames between the SoC and the PHY package, but maybe the PHYs
> themselves are down?
It shouldn't do. Each "channel" in the USXGMII-M link has its own
autoneg block at both ends, each conveys link status independently.
The MAC side structure is:
+----------+ +-----+
.-XGMII-> Rate | PCS | |
MAC1 <-MDI-> PHY <-+ | Adaption <--> Clause 49 <-> |
`-GMII--> | | |
+-----^----+ | |
| | |
+-----v---- + | |
| Autoneg | | |
| Clause 37 | | |
+-----------+ | |
| Mux <--> PMA <-->
| |
....... USXGMII-M
<------------------------------------------------------>
These blocks are repeated for each channel
The spec goes on to state that there must be a USXGMII enable bit that
defaults to disabled and the PHY should assume normal XGMII/XFI
operation. When enabled, autoneg follows a slight modification of
clause 37-6.
As far as the USXGMII-M link, I believe 2.7.8 in the USXGMII-M
documentation covers this, which is "hardware autoneg programming
sequence". It states that "if 10G link is lost or regained, the
software is expected to disable autoneg and re-enable autoneg". I
think "10G link" refers to the USXGMII-M connection, which means
the loss of that link shold cause software to intervene in each
of the PCS autoneg blocks. It is, however, rather unclear.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On 11/20/2023 5:29 PM, Russell King (Oracle) wrote:
> On Mon, Nov 20, 2023 at 04:49:59PM +0800, Jie Luo wrote:
>>
>>
>> On 11/19/2023 4:19 AM, Andrew Lunn wrote:
>>>> 10G_QXGMII is defined in the Cisco USXGMII multi-port document as one
>>>> of several possibilities for a USXGMII-M link. The Cisco document can
>>>> be a little confusing beause it states that 10G_QXGMII supports 10M,
>>>> 100M, 1G and 2.5G, and then only talks about a 10G and 100M/1G MAC.
>>>>
>>>> For 10G_QXGMII, there are 4 MAC interfaces. These are connected to a
>>>> rate "adaption" through symbol replication block, and then on to a
>>>> clause 49 PCS block.
>>>>
>>>> There is then a port MUX and framing block, followed by the PMA
>>>> serdes which communicates with the remote end over a single pair of
>>>> transmit/receive serdes lines.
>>>>
>>>> Each interface also has its own clause 37 autoneg block.
>>>>
>>>> So, for an interface to operate in SGMII mode, it would have to be
>>>> muxed to a different path before being presented to the USXGMII-M
>>>> block since each interface does not have its own external data lane
>>>> - thus that's out of scope of USXGMII-M as documented by Cisco.
>>>
>>> Hi Russell
>>>
>>> I think it helps.
>>>
>>> Where i'm having trouble is deciding if this is actually an interface
>>> mode. Interface mode is a per PHY property. Where as it seems
>>> 10G_QXGMII is a property of the USXGMII-M link? Should we be
>>> representing the package with 4 PHYs in it, and specify the package
>>> has a PMA which is using 10G_QXGMII over USXGMII-M? The PHY interface
>>> mode is then internal? Its just the link between the PHY and the MUX?
>>>
>>> By saying the interface mode is 10G_QXGMII and not describing the PMA
>>> mode, are we setting ourselves up for problems in the future? Could
>>> there be a PMA interface which could carry different PHY interface
>>> modes?
>>>
>>> If we decide we do want to use 10G_QXGMII as an interface made, i
>>> think the driver should be doing some validation. If asked to do
>>> anything else, it should return -EINVAL.
>>>
>>> And i don't yet understand how it can also do 1000BaseX and 2500BaseX
>>> and SGMII?
>>>
>>> Andrew
>>
>> Hi Andrew,
>> The interface mode 10G_QXGMII is a type of USXGMII-M, the other modes
>> such as 20G-QXGMII, 20G-OXGMII...
>>
>> As for the interface mode 10G-QXGMII, there is a multiplexer for 4 PHYs,
>> then do 66bit/68bit encode in xpcs and pass to PMA, the link topology:
>> quad PHY --- multiplexer ---XPCS --- PMA.
>> the 10G-QXGMII interface block includes multiplexer, XPCS and PMA.
>
> Note that phylink_pcs does *not* cover any PCS on the PHY device side
> of the link. It only covers a PCS on the MAC side.
Ok, even there is only one XPCS multiplex with 4 MACs, we should create
4 PCS instances for 4 MACs.
>
>> Here is a problem as Russell mentioned earlier, we need to know which PHY
>> device is changing the link status when the 10G-QXGMII mode is used,
>> since there are 4 PHYs, when one of them has the link change, there is no
>> PHY device information passed to the PHYLINK, so the PCS driver don't
>> which PHY is changing link status and 10G-QXGMII mode don't know which
>> channel(mapped to PHY) should be configured.
>>
>> would we add a field such as (int channel) in the struct phy_device?
>> so we can pass this information to PCS driver when the PHY link changed.
>
> Nothing in phylink nor phylib is setup to deal with "channels" within
> a PHY. The model assumes that a network interface consists of exactly
> one MAC associated with one active PHY.
>
> As there are 4 PHYs, phylib will expect there to be four PHY devices,
> and there will be expected to be four phylink instances.
>
make sense, thanks Russell.
On 11/20/2023 11:34 PM, Andrew Lunn wrote:
>> Hi Andrew,
>> The interface mode 10G_QXGMII is a type of USXGMII-M, the other modes
>> such as 20G-QXGMII, 20G-OXGMII...
>>
>> As for the interface mode 10G-QXGMII, there is a multiplexer for 4 PHYs,
>> then do 66bit/68bit encode in xpcs and pass to PMA, the link topology:
>> quad PHY --- multiplexer ---XPCS --- PMA.
>> the 10G-QXGMII interface block includes multiplexer, XPCS and PMA.
>>
>> when the PHY works on SGMII mode, then there is no xpcs, the only fourth
>> PHY of qca8084 can work on SGMII mode, the link topology:
>> the fourth PHY --- PCS --- PMA, the SGMII block includes PCS and PMA.
>
> What i missed is that you have two different PMA blocks. PHY4 can be
> muxed to either the QXGMII PMA or the 2500BaseX PMA. This is not clear
> in the commit message, and i think why you are getting questions about
> how 2500BaseX can work over QXGMII. Please expand you commit message
> to explain the architecture in more detail.
Ok, Andrew, i will give more detail about the pcs utilized in the next
patch set.
when pcs is configured to QXGMII mode, quad phy can reach to maximum
speed 2.5G, it is still in qxgmii mode.
when pcs is configured to SGMII mode, the fourth PHY can reach to
maximum speed 2.5G(2500BaseT) that is reached by increasing the clock
rate to 312.5MHZ from 125MHZ of 1G speed, but there is no corresponding
interface mode can be used to reflect this 2.5G speed mode(sgmii+), so
i use 2500BaseX to reflect this 2.5G link speed, which is same as
qca8081 PHY. Actually we should add a new interface mode such as sgmii+
to reflect this 2.5G speed of sgmii, so that the PHYLINK can support
all supported link speeds(10/100/1000/2500M) with the interface mode
sgmii+, currently 2500BaseX only advertise 2.5G, sgmii advertise
10/100/1000 in the PHYLINK framework. but actually qca808x supports
10/100/1000/2500 speed. how do you think?
>
> So, next question. How do you control what PMA PHY4 is connected to?
> Is this going to be based on interface mode? QXGMII it is configured
> to use the QXGMII PMA? SGMII, 1000BaseX, and 2500BaseX it is
> configured to the other PMA?
Yes, there are two different PCS to work on qxgmii and sgmii mode.
one PCS can be connected with quad phy, another pcs can be connected
with PHY4.
>
>> Here is a problem as Russell mentioned earlier, we need to know which PHY
>> device is changing the link status when the 10G-QXGMII mode is used,
>> since there are 4 PHYs, when one of them has the link change, there is no
>> PHY device information passed to the PHYLINK, so the PCS driver don't
>> which PHY is changing link status and 10G-QXGMII mode don't know which
>> channel(mapped to PHY) should be configured.
>
> This is the first time QXGMII has been seen in mainline, so its good
> to explain the background.
From PCS hardware perspective, there is only one QXGMII mode instance
for 4 PHYs and MACs, and the each PHY is related with the channel of
QXGMII.
>
> Are you saying there is a USXGMII-M level link change status? The link
> between the SoC and the PHY package is up/down? If it is down, all
> four MAC-PHY links are down. If it is up, it is possible to carry
> frames between the SoC and the PHY package, but maybe the PHYs
> themselves are down?
>
There is a per channel(for each PHY) configurations in XPCS XGMII mode,
if one PHY has the link change, the related channel should be
configured for this PHY, and multiplex is also used for the connected 4
MACs, the link change on one phy does not effect the other PHYs.
If the PHY is down, the pipeline of the related channel can't transfer
data, the phy link status is reflected to XPCS.
> Withing the four multiplex streams, is there a per stream link change
> indication?
Yes, it is per channel(for each PHY) link change indication in QXGMII.
>
> Andrew
On 11/21/2023 12:18 AM, Russell King (Oracle) wrote:
> On Mon, Nov 20, 2023 at 04:34:55PM +0100, Andrew Lunn wrote:
>> Are you saying there is a USXGMII-M level link change status? The link
>> between the SoC and the PHY package is up/down? If it is down, all
>> four MAC-PHY links are down. If it is up, it is possible to carry
>> frames between the SoC and the PHY package, but maybe the PHYs
>> themselves are down?
>
> It shouldn't do. Each "channel" in the USXGMII-M link has its own
> autoneg block at both ends, each conveys link status independently.
>
> The MAC side structure is:
>
>
> +----------+ +-----+
> .-XGMII-> Rate | PCS | |
> MAC1 <-MDI-> PHY <-+ | Adaption <--> Clause 49 <-> |
> `-GMII--> | | |
> +-----^----+ | |
> | | |
> +-----v---- + | |
> | Autoneg | | |
> | Clause 37 | | |
> +-----------+ | |
> | Mux <--> PMA <-->
> | |
> ....... USXGMII-M
>
> <------------------------------------------------------>
> These blocks are repeated for each channel
>
> The spec goes on to state that there must be a USXGMII enable bit that
> defaults to disabled and the PHY should assume normal XGMII/XFI
> operation. When enabled, autoneg follows a slight modification of
> clause 37-6.
>
> As far as the USXGMII-M link, I believe 2.7.8 in the USXGMII-M
> documentation covers this, which is "hardware autoneg programming
> sequence". It states that "if 10G link is lost or regained, the
> software is expected to disable autoneg and re-enable autoneg". I
> think "10G link" refers to the USXGMII-M connection, which means
> the loss of that link shold cause software to intervene in each
> of the PCS autoneg blocks. It is, however, rather unclear.
>
The link status of PHY is updated, software should do the corresponding
QXGMII mode configuration per channel for this PHY.
The PCS QXGMII configuration reflects the current link status of the
connected PHY.
On Tue, Nov 21, 2023 at 07:10:08PM +0800, Jie Luo wrote:
> when pcs is configured to SGMII mode, the fourth PHY can reach to
> maximum speed 2.5G(2500BaseT) that is reached by increasing the clock
> rate to 312.5MHZ from 125MHZ of 1G speed, but there is no corresponding
> interface mode can be used to reflect this 2.5G speed mode(sgmii+)
So this comes up again. 2.5G SGMII? What is that?
Let's start off with the basics. SGMII is Cisco's modification of
1000base-X. The two are broadly compatible in that they can communicate
with each other provided that the inband control word is disregarded.
2500base-X is generally implemented as 1000base-X over-clocked by 2.5x.
Some manufacturers state that the inband control word is not supported.
Others say it can be used. This disparity comes from the lack of early
IEEE standardisation of this protocol.
Cisco SGMII as defined is a 10M/100M/1G protocol operating at 125MHz
with a fixed underlying baud rate of 1250Mbaud. Slower speeds are
achieved via symbol replication by 10x or 100x. The inband control
word is modified in order to convey this speed information, as well
as duplex and sometimes also other vendor extensions.
Switching SGMII to be clocked 2.5x faster means that a partner that
expects SGMII at normal speed sees garbage - it can't recognise the
waveform. Therefore, it is not possible for inband to convey any
information. Many vendors explicitly state that symbol replication
is not supported when "SGMII" is clocked at 2.5x.
All variants of whatever the vendor calls the 2.5G mode tend to use
the SGMII term because... it's Serial Gigabit... and SGMII even gets
used by vendors to describe the interface used for 1000base-X.
Vendors use terms like "HS-SGMII" and other stuff to describe their
2.5x mode. Some use "2500base-X". Yours seems to use "SGMII+".
SGMII without inband signalling is basically the same as 1000base-X.
Therefore, SGMII clocked at 2.5x the speed is basically the same as
2500base-X without inband signalling.
So, the whole area is totally confused, and one should not get too
hung up on the terminology that vendors are using, but go back to
precisely what's going on at the hardware level.
We have raised this point almost every time someone talks about an
up-clocked "SGMII".
> Actually we should add a new interface mode such as sgmii+
> to reflect this 2.5G speed of sgmii
Only if there really is something different about it. For example,
if it were Cisco SGMII modified to operate always at 312.5MHz with
inband signalling updated to signal the four speeds. That would
definitely be a different protocol.
However, it's not that. What it actually is is Cisco SGMII when
operating at 10M/100M/1G speeds, and 2500base-X without inband
signalling when operating at 2.5G speed.
We have PHYs that support this (and more) which we support. PHYs
that switch between 10GBASE-R, 5GBASE-R, 2500BASE-X and Cisco SGMII
depending on the speed that was negotiated on the media. There is
no definition of a single interface mode that covers all those,
because it isn't a single interface mode. It's four separate modes
that the PHY switches between - and this is no different from what
is happening with your PHY.
Ultimately, you will need a way to use inband signalling with Cisco
SGMII for 10M/100M/1G speeds, and then switch to 2500base-X when
operating at 2.5G speeds, and that is done via the PHY driver
updating phydev->interface.
What we do need is some way for the PHY to also tell the PCS/MAC
whether inband should be used. This is something I keep bringing up
and now that we have PCS drivers revised to use the value from
phylink_pcs_neg_mode() _and_ a consistent implementation amongst them
we can now think about signalling to PCS drivers whether inband mode
needs to be turned off when switching between modes.
There have been patches in the past that allow inband mode to be
queried from phylib, and this is another important component in
properly dealing with PHYs that need to use inband signalling with
Cisco SGMII, but do not support inband signalling when operating at
2.5G speeds. The problem when operating at 2.5G speed is that the
base-X protocols are normally for use over fibre, which is the media,
and therefore the ethtool Autoneg bit should define whether inband
gets used or not. However, in the case of a PHY using 2500base-X,
the Autoneg bit continues to define whether autonegotiation should
be used on the media, and in this case it's the media side of the
PHY rather than the 2500base-X link.
So, when using a 2500base-X link to a PHY, we need to disregard the
Autoneg bit, but that then raises the question about how we should
configure it - and one solution to that would be to entire of phylib
what the PHY wants to do. Another is to somehow ask the PCS driver
whether it supports inband signalling at 2500base-X, and resolve
those capabilities.
That is my view where we need to get to in order to properly resolve
the ongoing issues about 2500base-X and PHYs that make use of that.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On 11/21/2023 7:52 PM, Russell King (Oracle) wrote:
> On Tue, Nov 21, 2023 at 07:10:08PM +0800, Jie Luo wrote:
>> when pcs is configured to SGMII mode, the fourth PHY can reach to
>> maximum speed 2.5G(2500BaseT) that is reached by increasing the clock
>> rate to 312.5MHZ from 125MHZ of 1G speed, but there is no corresponding
>> interface mode can be used to reflect this 2.5G speed mode(sgmii+)
>
> So this comes up again. 2.5G SGMII? What is that?
2.5G SGMII here is reached by increasing the PCS clock rate to 312.5MHZ
from sgmii with the clock rate 125MHZ.
>
> Let's start off with the basics. SGMII is Cisco's modification of
> 1000base-X. The two are broadly compatible in that they can communicate
> with each other provided that the inband control word is disregarded.
>
> 2500base-X is generally implemented as 1000base-X over-clocked by 2.5x.
> Some manufacturers state that the inband control word is not supported.
> Others say it can be used. This disparity comes from the lack of early
> IEEE standardisation of this protocol.
>
> Cisco SGMII as defined is a 10M/100M/1G protocol operating at 125MHz
> with a fixed underlying baud rate of 1250Mbaud. Slower speeds are
> achieved via symbol replication by 10x or 100x. The inband control
> word is modified in order to convey this speed information, as well
> as duplex and sometimes also other vendor extensions.
>
> Switching SGMII to be clocked 2.5x faster means that a partner that
> expects SGMII at normal speed sees garbage - it can't recognise the
> waveform. Therefore, it is not possible for inband to convey any
> information. Many vendors explicitly state that symbol replication
> is not supported when "SGMII" is clocked at 2.5x.
>
> All variants of whatever the vendor calls the 2.5G mode tend to use
> the SGMII term because... it's Serial Gigabit... and SGMII even gets
> used by vendors to describe the interface used for 1000base-X.
> Vendors use terms like "HS-SGMII" and other stuff to describe their
> 2.5x mode. Some use "2500base-X". Yours seems to use "SGMII+".
i use the term SGMII+ because of the 2.5G speed achieved by operating
the clock rate in 312.5MHZ from 1G speed of 125MHZ.
>
> SGMII without inband signalling is basically the same as 1000base-X.
> Therefore, SGMII clocked at 2.5x the speed is basically the same as
> 2500base-X without inband signalling.
SGMII+ disable the autoneg when the serdes works 312.5MHZ for the 2.5
link speed.
>
> So, the whole area is totally confused, and one should not get too
> hung up on the terminology that vendors are using, but go back to
> precisely what's going on at the hardware level.
>
> We have raised this point almost every time someone talks about an
> up-clocked "SGMII".
>
>
>> Actually we should add a new interface mode such as sgmii+
>> to reflect this 2.5G speed of sgmii
>
> Only if there really is something different about it. For example,
> if it were Cisco SGMII modified to operate always at 312.5MHz with
> inband signalling updated to signal the four speeds. That would
> definitely be a different protocol.
For qca808x PHY, the clock rate is different between sgmii(125MHZ for
speed 10/100/1000M) and sgmii+(312.5MHZ for 2.5G).
>
> However, it's not that. What it actually is is Cisco SGMII when
> operating at 10M/100M/1G speeds, and 2500base-X without inband
> signalling when operating at 2.5G speed.
Yes, Russell, this is what qca808x PHY works on.
>
> We have PHYs that support this (and more) which we support. PHYs
> that switch between 10GBASE-R, 5GBASE-R, 2500BASE-X and Cisco SGMII
> depending on the speed that was negotiated on the media. There is
> no definition of a single interface mode that covers all those,
> because it isn't a single interface mode. It's four separate modes
> that the PHY switches between - and this is no different from what
> is happening with your PHY.
This is indeed two different modes switched between 2.5G and other
speeds(10/100/1000M).
>
> Ultimately, you will need a way to use inband signalling with Cisco
> SGMII for 10M/100M/1G speeds, and then switch to 2500base-X when
> operating at 2.5G speeds, and that is done via the PHY driver
> updating phydev->interface.
>
> What we do need is some way for the PHY to also tell the PCS/MAC
> whether inband should be used. This is something I keep bringing up
> and now that we have PCS drivers revised to use the value from
> phylink_pcs_neg_mode() _and_ a consistent implementation amongst them
> we can now think about signalling to PCS drivers whether inband mode
> needs to be turned off when switching between modes.
Yes, we can switch the interface mode according to the current link
speed in the pcs driver.
but the issue is that the phy-mode i specified for the PHYLINK,
if phy-mode is sgmii, the support capability is limited to maximum
capability 1G during the PHYLINK setup and i can't configure it to 2.5G
dynamically, if the phy-mode is 2500base-x, then PHY capability will
be modified to only support 2.5G, other speeds can't be linked up.
>
> There have been patches in the past that allow inband mode to be
> queried from phylib, and this is another important component in
> properly dealing with PHYs that need to use inband signalling with
> Cisco SGMII, but do not support inband signalling when operating at
> 2.5G speeds. The problem when operating at 2.5G speed is that the
> base-X protocols are normally for use over fibre, which is the media,
> and therefore the ethtool Autoneg bit should define whether inband
> gets used or not. However, in the case of a PHY using 2500base-X,
> the Autoneg bit continues to define whether autonegotiation should
> be used on the media, and in this case it's the media side of the
> PHY rather than the 2500base-X link.
>
> So, when using a 2500base-X link to a PHY, we need to disregard the
> Autoneg bit, but that then raises the question about how we should
> configure it - and one solution to that would be to entire of phylib
> what the PHY wants to do. Another is to somehow ask the PCS driver
> whether it supports inband signalling at 2500base-X, and resolve
> those capabilities.
For the qca808x PHY, when it is linked in 2.5G, the autoneg is also
disabled in PCS hardware, so the sgmii+ of qca808x PHY is almost
same as 2500base-X.
>
> That is my view where we need to get to in order to properly resolve
> the ongoing issues about 2500base-X and PHYs that make use of that.
>
Thanks Russell for the detail information about the SGMII and 2500BASE-X
mode, it is really helpful.
For now, the issue is "the Supported link modes" of PHY is limited when
the interface mode(such as sgmii) is used to setup PHYLINK, which leads
to the PHY can't link in the speed(such as 2.5G) of the different
interface mode(sgmii+).
On Thu, Nov 23, 2023 at 06:57:59PM +0800, Jie Luo wrote:
> On 11/21/2023 7:52 PM, Russell King (Oracle) wrote:
> > Ultimately, you will need a way to use inband signalling with Cisco
> > SGMII for 10M/100M/1G speeds, and then switch to 2500base-X when
> > operating at 2.5G speeds, and that is done via the PHY driver
> > updating phydev->interface.
> >
> > What we do need is some way for the PHY to also tell the PCS/MAC
> > whether inband should be used. This is something I keep bringing up
> > and now that we have PCS drivers revised to use the value from
> > phylink_pcs_neg_mode() _and_ a consistent implementation amongst them
> > we can now think about signalling to PCS drivers whether inband mode
> > needs to be turned off when switching between modes.
>
> Yes, we can switch the interface mode according to the current link
> speed in the pcs driver.
> but the issue is that the phy-mode i specified for the PHYLINK,
> if phy-mode is sgmii, the support capability is limited to maximum
> capability 1G during the PHYLINK setup and i can't configure it to 2.5G
> dynamically, if the phy-mode is 2500base-x, then PHY capability will
> be modified to only support 2.5G, other speeds can't be linked up.
So you need my patches that add "possible_interfaces" to phylib so you
can tell phylink that you will be switching between SGMII and
2500base-X. Please see the RFC posting of those patches I sent
yesterday and try them out - you will need to modify your phylib
driver to fill in phydev->possible_interfaces.
> > There have been patches in the past that allow inband mode to be
> > queried from phylib, and this is another important component in
> > properly dealing with PHYs that need to use inband signalling with
> > Cisco SGMII, but do not support inband signalling when operating at
> > 2.5G speeds. The problem when operating at 2.5G speed is that the
> > base-X protocols are normally for use over fibre, which is the media,
> > and therefore the ethtool Autoneg bit should define whether inband
> > gets used or not. However, in the case of a PHY using 2500base-X,
> > the Autoneg bit continues to define whether autonegotiation should
> > be used on the media, and in this case it's the media side of the
> > PHY rather than the 2500base-X link.
> >
> > So, when using a 2500base-X link to a PHY, we need to disregard the
> > Autoneg bit, but that then raises the question about how we should
> > configure it - and one solution to that would be to entire of phylib
> > what the PHY wants to do. Another is to somehow ask the PCS driver
> > whether it supports inband signalling at 2500base-X, and resolve
> > those capabilities.
>
> For the qca808x PHY, when it is linked in 2.5G, the autoneg is also
> disabled in PCS hardware, so the sgmii+ of qca808x PHY is almost
> same as 2500base-X.
Not "almost". It _is_ the same. This is the point I've been trying
to get across to you. Without inband signalling, 1000base-X and SGMII
(when operating at 1G) are _identical_ and entirely compatible.
You've said that your 2.5G "SGMII" mode has inband signalling disabled,
and thus it without inband signalling, 2500base-X and this 2.5G mode
are again identical and entirely compatible. There's no "almost" about
it.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On 11/23/2023 8:01 PM, Russell King (Oracle) wrote:
> On Thu, Nov 23, 2023 at 06:57:59PM +0800, Jie Luo wrote:
>> On 11/21/2023 7:52 PM, Russell King (Oracle) wrote:
>>> Ultimately, you will need a way to use inband signalling with Cisco
>>> SGMII for 10M/100M/1G speeds, and then switch to 2500base-X when
>>> operating at 2.5G speeds, and that is done via the PHY driver
>>> updating phydev->interface.
>>>
>>> What we do need is some way for the PHY to also tell the PCS/MAC
>>> whether inband should be used. This is something I keep bringing up
>>> and now that we have PCS drivers revised to use the value from
>>> phylink_pcs_neg_mode() _and_ a consistent implementation amongst them
>>> we can now think about signalling to PCS drivers whether inband mode
>>> needs to be turned off when switching between modes.
>>
>> Yes, we can switch the interface mode according to the current link
>> speed in the pcs driver.
>> but the issue is that the phy-mode i specified for the PHYLINK,
>> if phy-mode is sgmii, the support capability is limited to maximum
>> capability 1G during the PHYLINK setup and i can't configure it to 2.5G
>> dynamically, if the phy-mode is 2500base-x, then PHY capability will
>> be modified to only support 2.5G, other speeds can't be linked up.
>
> So you need my patches that add "possible_interfaces" to phylib so you
> can tell phylink that you will be switching between SGMII and
> 2500base-X. Please see the RFC posting of those patches I sent
> yesterday and try them out - you will need to modify your phylib
> driver to fill in phydev->possible_interfaces.
Your patches work on my board, thanks Russell.
>
>>> There have been patches in the past that allow inband mode to be
>>> queried from phylib, and this is another important component in
>>> properly dealing with PHYs that need to use inband signalling with
>>> Cisco SGMII, but do not support inband signalling when operating at
>>> 2.5G speeds. The problem when operating at 2.5G speed is that the
>>> base-X protocols are normally for use over fibre, which is the media,
>>> and therefore the ethtool Autoneg bit should define whether inband
>>> gets used or not. However, in the case of a PHY using 2500base-X,
>>> the Autoneg bit continues to define whether autonegotiation should
>>> be used on the media, and in this case it's the media side of the
>>> PHY rather than the 2500base-X link.
>>>
>>> So, when using a 2500base-X link to a PHY, we need to disregard the
>>> Autoneg bit, but that then raises the question about how we should
>>> configure it - and one solution to that would be to entire of phylib
>>> what the PHY wants to do. Another is to somehow ask the PCS driver
>>> whether it supports inband signalling at 2500base-X, and resolve
>>> those capabilities.
>>
>> For the qca808x PHY, when it is linked in 2.5G, the autoneg is also
>> disabled in PCS hardware, so the sgmii+ of qca808x PHY is almost
>> same as 2500base-X.
>
> Not "almost". It _is_ the same. This is the point I've been trying
> to get across to you. Without inband signalling, 1000base-X and SGMII
> (when operating at 1G) are _identical_ and entirely compatible.
>
> You've said that your 2.5G "SGMII" mode has inband signalling disabled,
> and thus it without inband signalling, 2500base-X and this 2.5G mode
> are again identical and entirely compatible. There's no "almost" about
> it.
>
>
Yes, confirmed with HW guy, they work on the same way.
On Fri, Nov 24, 2023 at 05:47:04PM +0800, Jie Luo wrote:
>
>
> On 11/23/2023 8:01 PM, Russell King (Oracle) wrote:
> > On Thu, Nov 23, 2023 at 06:57:59PM +0800, Jie Luo wrote:
> > > On 11/21/2023 7:52 PM, Russell King (Oracle) wrote:
> > > > Ultimately, you will need a way to use inband signalling with Cisco
> > > > SGMII for 10M/100M/1G speeds, and then switch to 2500base-X when
> > > > operating at 2.5G speeds, and that is done via the PHY driver
> > > > updating phydev->interface.
> > > >
> > > > What we do need is some way for the PHY to also tell the PCS/MAC
> > > > whether inband should be used. This is something I keep bringing up
> > > > and now that we have PCS drivers revised to use the value from
> > > > phylink_pcs_neg_mode() _and_ a consistent implementation amongst them
> > > > we can now think about signalling to PCS drivers whether inband mode
> > > > needs to be turned off when switching between modes.
> > >
> > > Yes, we can switch the interface mode according to the current link
> > > speed in the pcs driver.
> > > but the issue is that the phy-mode i specified for the PHYLINK,
> > > if phy-mode is sgmii, the support capability is limited to maximum
> > > capability 1G during the PHYLINK setup and i can't configure it to 2.5G
> > > dynamically, if the phy-mode is 2500base-x, then PHY capability will
> > > be modified to only support 2.5G, other speeds can't be linked up.
> >
> > So you need my patches that add "possible_interfaces" to phylib so you
> > can tell phylink that you will be switching between SGMII and
> > 2500base-X. Please see the RFC posting of those patches I sent
> > yesterday and try them out - you will need to modify your phylib
> > driver to fill in phydev->possible_interfaces.
>
> Your patches work on my board, thanks Russell.
Please can you reply to the covering email for that series giving your
tested-by? Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On 11/24/2023 5:53 PM, Russell King (Oracle) wrote:
> On Fri, Nov 24, 2023 at 05:47:04PM +0800, Jie Luo wrote:
>>
>>
>> On 11/23/2023 8:01 PM, Russell King (Oracle) wrote:
>>> On Thu, Nov 23, 2023 at 06:57:59PM +0800, Jie Luo wrote:
>>>> On 11/21/2023 7:52 PM, Russell King (Oracle) wrote:
>>>>> Ultimately, you will need a way to use inband signalling with Cisco
>>>>> SGMII for 10M/100M/1G speeds, and then switch to 2500base-X when
>>>>> operating at 2.5G speeds, and that is done via the PHY driver
>>>>> updating phydev->interface.
>>>>>
>>>>> What we do need is some way for the PHY to also tell the PCS/MAC
>>>>> whether inband should be used. This is something I keep bringing up
>>>>> and now that we have PCS drivers revised to use the value from
>>>>> phylink_pcs_neg_mode() _and_ a consistent implementation amongst them
>>>>> we can now think about signalling to PCS drivers whether inband mode
>>>>> needs to be turned off when switching between modes.
>>>>
>>>> Yes, we can switch the interface mode according to the current link
>>>> speed in the pcs driver.
>>>> but the issue is that the phy-mode i specified for the PHYLINK,
>>>> if phy-mode is sgmii, the support capability is limited to maximum
>>>> capability 1G during the PHYLINK setup and i can't configure it to 2.5G
>>>> dynamically, if the phy-mode is 2500base-x, then PHY capability will
>>>> be modified to only support 2.5G, other speeds can't be linked up.
>>>
>>> So you need my patches that add "possible_interfaces" to phylib so you
>>> can tell phylink that you will be switching between SGMII and
>>> 2500base-X. Please see the RFC posting of those patches I sent
>>> yesterday and try them out - you will need to modify your phylib
>>> driver to fill in phydev->possible_interfaces.
>>
>> Your patches work on my board, thanks Russell.
>
> Please can you reply to the covering email for that series giving your
> tested-by? Thanks.
>
Ok.