* [PATCH net-next v2 0/8] rework phylink interface for split MAC/PCS support
@ 2020-02-26 10:23 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Hi,
The following series changes the phylink interface to allow us to
better support split MAC / MAC PCS setups. The fundamental change
required for this turns out to be quite simple.
Today, mac_config() is used for everything to do with setting the
parameters for the MAC, and mac_link_up() is used to inform the
MAC driver that the link is now up (and so to allow packet flow.)
mac_config() also has had a few implementation issues, with folk
who believe that members such as "speed" and "duplex" are always
valid, where "link" gets used inappropriately, etc.
With the proposed patches, all this changes subtly - but in a
backwards compatible way at this stage.
We pass the the full resolved link state (speed, duplex, pause) to
mac_link_up(), and it is now guaranteed that these parameters to
this function will always be valid (no more SPEED_UNKNOWN or
DUPLEX_UNKNOWN here - unless phylink is fed with such things.)
Drivers should convert over to using the state in mac_link_up()
rather than configuring the speed, duplex and pause in the
mac_config() method. The patch series includes a number of MAC
drivers which I've thought have been easy targets - I've left the
remainder as I think they need maintainer input. However, *all*
drivers will need conversion for future phylink development.
v2: add ocelot/felix and qca/ar9331 DSA drivers to patch 2, add
received tested-by so far.
Documentation/networking/sfp-phylink.rst | 17 +++-
drivers/net/dsa/b53/b53_common.c | 4 +-
drivers/net/dsa/b53/b53_priv.h | 4 +-
drivers/net/dsa/bcm_sf2.c | 4 +-
drivers/net/dsa/lantiq_gswip.c | 4 +-
drivers/net/dsa/mt7530.c | 4 +-
drivers/net/dsa/mv88e6xxx/chip.c | 79 +++++++++++++----
drivers/net/dsa/ocelot/felix.c | 4 +-
drivers/net/dsa/qca/ar9331.c | 4 +-
drivers/net/dsa/sja1105/sja1105_main.c | 4 +-
drivers/net/ethernet/cadence/macb.h | 1 -
drivers/net/ethernet/cadence/macb_main.c | 57 +++++++-----
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c | 61 ++++++++-----
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h | 1 +
drivers/net/ethernet/marvell/mvneta.c | 63 ++++++++-----
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 102 +++++++++++++---------
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 37 ++++----
drivers/net/phy/phylink.c | 9 +-
include/linux/phylink.h | 57 ++++++++----
include/net/dsa.h | 4 +-
net/dsa/port.c | 7 +-
23 files changed, 358 insertions(+), 180 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply [flat|nested] 60+ messages in thread
* [PATCH net-next v2 0/8] rework phylink interface for split MAC/PCS support
@ 2020-02-26 10:23 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Vivien Didelot, Radhey Shyam Pandey, Alexandre Torgue,
Hauke Mehrtens, Sean Wang, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Mark Lee, Maxime Coquelin, Vladimir Oltean, David S. Miller,
Felix Fietkau
Hi,
The following series changes the phylink interface to allow us to
better support split MAC / MAC PCS setups. The fundamental change
required for this turns out to be quite simple.
Today, mac_config() is used for everything to do with setting the
parameters for the MAC, and mac_link_up() is used to inform the
MAC driver that the link is now up (and so to allow packet flow.)
mac_config() also has had a few implementation issues, with folk
who believe that members such as "speed" and "duplex" are always
valid, where "link" gets used inappropriately, etc.
With the proposed patches, all this changes subtly - but in a
backwards compatible way at this stage.
We pass the the full resolved link state (speed, duplex, pause) to
mac_link_up(), and it is now guaranteed that these parameters to
this function will always be valid (no more SPEED_UNKNOWN or
DUPLEX_UNKNOWN here - unless phylink is fed with such things.)
Drivers should convert over to using the state in mac_link_up()
rather than configuring the speed, duplex and pause in the
mac_config() method. The patch series includes a number of MAC
drivers which I've thought have been easy targets - I've left the
remainder as I think they need maintainer input. However, *all*
drivers will need conversion for future phylink development.
v2: add ocelot/felix and qca/ar9331 DSA drivers to patch 2, add
received tested-by so far.
Documentation/networking/sfp-phylink.rst | 17 +++-
drivers/net/dsa/b53/b53_common.c | 4 +-
drivers/net/dsa/b53/b53_priv.h | 4 +-
drivers/net/dsa/bcm_sf2.c | 4 +-
drivers/net/dsa/lantiq_gswip.c | 4 +-
drivers/net/dsa/mt7530.c | 4 +-
drivers/net/dsa/mv88e6xxx/chip.c | 79 +++++++++++++----
drivers/net/dsa/ocelot/felix.c | 4 +-
drivers/net/dsa/qca/ar9331.c | 4 +-
drivers/net/dsa/sja1105/sja1105_main.c | 4 +-
drivers/net/ethernet/cadence/macb.h | 1 -
drivers/net/ethernet/cadence/macb_main.c | 57 +++++++-----
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c | 61 ++++++++-----
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h | 1 +
drivers/net/ethernet/marvell/mvneta.c | 63 ++++++++-----
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 102 +++++++++++++---------
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 37 ++++----
drivers/net/phy/phylink.c | 9 +-
include/linux/phylink.h | 57 ++++++++----
include/net/dsa.h | 4 +-
net/dsa/port.c | 7 +-
23 files changed, 358 insertions(+), 180 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* [PATCH net-next v2 0/8] rework phylink interface for split MAC/PCS support
@ 2020-02-26 10:23 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Vivien Didelot, Radhey Shyam Pandey, Alexandre Torgue,
Hauke Mehrtens, Sean Wang, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Mark Lee, Maxime Coquelin, Vladimir Oltean, David S. Miller,
Felix Fietkau
Hi,
The following series changes the phylink interface to allow us to
better support split MAC / MAC PCS setups. The fundamental change
required for this turns out to be quite simple.
Today, mac_config() is used for everything to do with setting the
parameters for the MAC, and mac_link_up() is used to inform the
MAC driver that the link is now up (and so to allow packet flow.)
mac_config() also has had a few implementation issues, with folk
who believe that members such as "speed" and "duplex" are always
valid, where "link" gets used inappropriately, etc.
With the proposed patches, all this changes subtly - but in a
backwards compatible way at this stage.
We pass the the full resolved link state (speed, duplex, pause) to
mac_link_up(), and it is now guaranteed that these parameters to
this function will always be valid (no more SPEED_UNKNOWN or
DUPLEX_UNKNOWN here - unless phylink is fed with such things.)
Drivers should convert over to using the state in mac_link_up()
rather than configuring the speed, duplex and pause in the
mac_config() method. The patch series includes a number of MAC
drivers which I've thought have been easy targets - I've left the
remainder as I think they need maintainer input. However, *all*
drivers will need conversion for future phylink development.
v2: add ocelot/felix and qca/ar9331 DSA drivers to patch 2, add
received tested-by so far.
Documentation/networking/sfp-phylink.rst | 17 +++-
drivers/net/dsa/b53/b53_common.c | 4 +-
drivers/net/dsa/b53/b53_priv.h | 4 +-
drivers/net/dsa/bcm_sf2.c | 4 +-
drivers/net/dsa/lantiq_gswip.c | 4 +-
drivers/net/dsa/mt7530.c | 4 +-
drivers/net/dsa/mv88e6xxx/chip.c | 79 +++++++++++++----
drivers/net/dsa/ocelot/felix.c | 4 +-
drivers/net/dsa/qca/ar9331.c | 4 +-
drivers/net/dsa/sja1105/sja1105_main.c | 4 +-
drivers/net/ethernet/cadence/macb.h | 1 -
drivers/net/ethernet/cadence/macb_main.c | 57 +++++++-----
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c | 61 ++++++++-----
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h | 1 +
drivers/net/ethernet/marvell/mvneta.c | 63 ++++++++-----
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 102 +++++++++++++---------
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 37 ++++----
drivers/net/phy/phylink.c | 9 +-
include/linux/phylink.h | 57 ++++++++----
include/net/dsa.h | 4 +-
net/dsa/port.c | 7 +-
23 files changed, 358 insertions(+), 180 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
* [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
2020-02-26 10:23 ` Russell King - ARM Linux admin
(?)
@ 2020-02-26 10:23 ` Russell King
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: Alexandre Torgue, David S. Miller, Felix Fietkau,
Giuseppe Cavallaro, Hauke Mehrtens, Ioana Ciornei,
Jakub Kicinski, John Crispin, Jonathan Corbet, Jose Abreu,
linux-arm-kernel, linux-doc, linux-mediatek, linux-stm32,
Mark Lee, Matthias Brugger, Maxime Coquelin, Michal Simek,
netdev, Nicolas Ferre, Radhey Shyam Pandey, Sean Wang,
Thomas Petazzoni, Vivien Didelot, Vladimir Oltean,
Ioana Radulescu
Propagate the resolved link parameters via the mac_link_up() call for
MACs that do not automatically track their PCS state. We propagate the
link parameters via function arguments so that inappropriate members
of struct phylink_link_state can't be accessed, and creating a new
structure just for this adds needless complexity to the API.
Tested-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
Documentation/networking/sfp-phylink.rst | 17 +++++-
drivers/net/ethernet/cadence/macb_main.c | 7 ++-
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
drivers/net/ethernet/marvell/mvneta.c | 8 ++-
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
.../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
drivers/net/phy/phylink.c | 9 ++-
include/linux/phylink.h | 57 ++++++++++++++-----
net/dsa/port.c | 4 +-
11 files changed, 105 insertions(+), 41 deletions(-)
diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
index d753a309f9d1..8d7af28cd835 100644
--- a/Documentation/networking/sfp-phylink.rst
+++ b/Documentation/networking/sfp-phylink.rst
@@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
this documentation.
1. Optionally split the network driver's phylib update function into
- three parts dealing with link-down, link-up and reconfiguring the
- MAC settings. This can be done as a separate preparation commit.
+ two parts dealing with link-down and link-up. This can be done as
+ a separate preparation commit.
- An example of this preparation can be found in git commit fc548b991fb0.
+ An older example of this preparation can be found in git commit
+ fc548b991fb0, although this was splitting into three parts; the
+ link-up part now includes configuring the MAC for the link settings.
+ Please see :c:func:`mac_link_up` for more information on this.
2. Replace::
@@ -207,6 +210,14 @@ this documentation.
using. This is particularly important for in-band negotiation
methods such as 1000base-X and SGMII.
+ The :c:func:`mac_link_up` method is used to inform the MAC that the
+ link has come up. The call includes the negotiation mode and interface
+ for reference only. The finalised link parameters are also supplied
+ (speed, duplex and flow control/pause enablement settings) which
+ should be used to configure the MAC when the MAC and PCS are not
+ tightly integrated, or when the settings are not coming from in-band
+ negotiation.
+
The :c:func:`mac_config` method is used to update the MAC with the
requested state, and must avoid unnecessarily taking the link down
when making changes to the MAC configuration. This means the
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 2c28da1737fe..7ab0bef5e1bd 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -626,8 +626,11 @@ static void macb_mac_link_down(struct phylink_config *config, unsigned int mode,
netif_tx_stop_all_queues(ndev);
}
-static void macb_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy)
+static void macb_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *ndev = to_net_dev(config->dev);
struct macb *bp = netdev_priv(ndev);
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
index 84233e467ed1..3a75c5b58f95 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
@@ -154,8 +154,11 @@ static void dpaa2_mac_config(struct phylink_config *config, unsigned int mode,
netdev_err(mac->net_dev, "dpmac_set_link_state() = %d\n", err);
}
-static void dpaa2_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy)
+static void dpaa2_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct dpaa2_mac *mac = phylink_to_dpaa2_mac(config);
struct dpmac_link_state *dpmac_state = &mac->state;
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 1c391f63a26f..9af3f8d5b289 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3965,9 +3965,11 @@ static void mvneta_mac_link_down(struct phylink_config *config,
mvneta_set_eee(pp, false);
}
-static void mvneta_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy)
+static void mvneta_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *ndev = to_net_dev(config->dev);
struct mvneta_port *pp = netdev_priv(ndev);
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 72133cbe55d4..ed8042d97e29 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -58,8 +58,11 @@ static struct {
*/
static void mvpp2_mac_config(struct phylink_config *config, unsigned int mode,
const struct phylink_link_state *state);
-static void mvpp2_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy);
+static void mvpp2_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause);
/* Queue modes */
#define MVPP2_QDIST_SINGLE_MODE 0
@@ -3473,8 +3476,9 @@ static void mvpp2_start_dev(struct mvpp2_port *port)
.interface = port->phy_interface,
};
mvpp2_mac_config(&port->phylink_config, MLO_AN_INBAND, &state);
- mvpp2_mac_link_up(&port->phylink_config, MLO_AN_INBAND,
- port->phy_interface, NULL);
+ mvpp2_mac_link_up(&port->phylink_config, NULL,
+ MLO_AN_INBAND, port->phy_interface,
+ SPEED_UNKNOWN, DUPLEX_UNKNOWN, false, false);
}
netif_tx_start_all_queues(port->dev);
@@ -5141,8 +5145,11 @@ static void mvpp2_mac_config(struct phylink_config *config, unsigned int mode,
mvpp2_port_enable(port);
}
-static void mvpp2_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy)
+static void mvpp2_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *dev = to_net_dev(config->dev);
struct mvpp2_port *port = netdev_priv(dev);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8c6cfd15481c..8d28f90acfe7 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -412,9 +412,10 @@ static void mtk_mac_link_down(struct phylink_config *config, unsigned int mode,
mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id));
}
-static void mtk_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy)
+static void mtk_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex, bool tx_pause, bool rx_pause)
{
struct mtk_mac *mac = container_of(config, struct mtk_mac,
phylink_config);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 37920b4da091..e039e715dcee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -950,8 +950,10 @@ static void stmmac_mac_link_down(struct phylink_config *config,
}
static void stmmac_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
unsigned int mode, phy_interface_t interface,
- struct phy_device *phy)
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 20746b801959..197740781157 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1486,9 +1486,10 @@ static void axienet_mac_link_down(struct phylink_config *config,
}
static void axienet_mac_link_up(struct phylink_config *config,
- unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy)
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
/* nothing meaningful to do */
}
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 2899fbe699ab..b4367fab7899 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -480,8 +480,11 @@ static void phylink_mac_link_up(struct phylink *pl,
struct net_device *ndev = pl->netdev;
pl->cur_interface = link_state.interface;
- pl->ops->mac_link_up(pl->config, pl->cur_link_an_mode,
- pl->cur_interface, pl->phydev);
+ pl->ops->mac_link_up(pl->config, pl->phydev,
+ pl->cur_link_an_mode, pl->cur_interface,
+ link_state.speed, link_state.duplex,
+ !!(link_state.pause & MLO_PAUSE_TX),
+ !!(link_state.pause & MLO_PAUSE_RX));
if (ndev)
netif_carrier_on(ndev);
@@ -547,6 +550,8 @@ static void phylink_resolve(struct work_struct *w)
link_state.pause = pl->phy_state.pause;
phylink_apply_manual_flow(pl, &link_state);
phylink_mac_config(pl, &link_state);
+ } else {
+ phylink_apply_manual_flow(pl, &link_state);
}
break;
}
diff --git a/include/linux/phylink.h b/include/linux/phylink.h
index 812357c03df4..2180eb1aa254 100644
--- a/include/linux/phylink.h
+++ b/include/linux/phylink.h
@@ -91,9 +91,10 @@ struct phylink_mac_ops {
void (*mac_an_restart)(struct phylink_config *config);
void (*mac_link_down)(struct phylink_config *config, unsigned int mode,
phy_interface_t interface);
- void (*mac_link_up)(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy);
+ void (*mac_link_up)(struct phylink_config *config,
+ struct phy_device *phy, unsigned int mode,
+ phy_interface_t interface, int speed, int duplex,
+ bool tx_pause, bool rx_pause);
};
#if 0 /* For kernel-doc purposes only. */
@@ -152,6 +153,9 @@ void mac_pcs_get_state(struct phylink_config *config,
* guaranteed to be correct, and so any mac_config() implementation must
* never reference these fields.
*
+ * (this requires a rewrite - please refer to mac_link_up() for situations
+ * where the PCS and MAC are not tightly integrated.)
+ *
* In all negotiation modes, as defined by @mode, @state->pause indicates the
* pause settings which should be applied as follows. If %MLO_PAUSE_AN is not
* set, %MLO_PAUSE_TX and %MLO_PAUSE_RX indicate whether the MAC should send
@@ -162,12 +166,20 @@ void mac_pcs_get_state(struct phylink_config *config,
* The action performed depends on the currently selected mode:
*
* %MLO_AN_FIXED, %MLO_AN_PHY:
- * Configure the specified @state->speed and @state->duplex over a link
- * specified by @state->interface. @state->advertising may be used, but
- * is not required. Pause modes as above. Other members of @state must
- * be ignored.
+ * Configure for non-inband negotiation mode, where the link settings
+ * are completely communicated via mac_link_up(). The physical link
+ * protocol from the MAC is specified by @state->interface.
+ *
+ * @state->advertising may be used, but is not required.
+ *
+ * Older drivers (prior to the mac_link_up() change) may use @state->speed,
+ * @state->duplex and @state->pause to configure the MAC, but this is
+ * deprecated; such drivers should be converted to use mac_link_up().
*
- * Valid state members: interface, speed, duplex, pause, advertising.
+ * Other members of @state must be ignored.
+ *
+ * Valid state members: interface, advertising.
+ * Deprecated state members: speed, duplex, pause.
*
* %MLO_AN_INBAND:
* place the link in an inband negotiation mode (such as 802.3z
@@ -228,19 +240,34 @@ void mac_link_down(struct phylink_config *config, unsigned int mode,
/**
* mac_link_up() - allow the link to come up
* @config: a pointer to a &struct phylink_config.
+ * @phy: any attached phy
* @mode: link autonegotiation mode
* @interface: link &typedef phy_interface_t mode
- * @phy: any attached phy
+ * @speed: link speed
+ * @duplex: link duplex
+ * @tx_pause: link transmit pause enablement status
+ * @rx_pause: link receive pause enablement status
*
- * If @mode is not an in-band negotiation mode (as defined by
- * phylink_autoneg_inband()), allow the link to come up. If @phy
- * is non-%NULL, configure Energy Efficient Ethernet by calling
+ * Configure the MAC for an established link.
+ *
+ * @speed, @duplex, @tx_pause and @rx_pause indicate the finalised link
+ * settings, and should be used to configure the MAC block appropriately
+ * where these settings are not automatically conveyed from the PCS block,
+ * or if in-band negotiation (as defined by phylink_autoneg_inband(@mode))
+ * is disabled.
+ *
+ * Note that when 802.3z in-band negotiation is in use, it is possible
+ * that the user wishes to override the pause settings, and this should
+ * be allowed when considering the implementation of this method.
+ *
+ * If in-band negotiation mode is disabled, allow the link to come up. If
+ * @phy is non-%NULL, configure Energy Efficient Ethernet by calling
* phy_init_eee() and perform appropriate MAC configuration for EEE.
* Interface type selection must be done in mac_config().
*/
-void mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy);
+void mac_link_up(struct phylink_config *config, struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex, bool tx_pause, bool rx_pause);
#endif
struct phylink *phylink_create(struct phylink_config *, struct fwnode_handle *,
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 774facb8d547..b2f5262b35cf 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -489,9 +489,11 @@ static void dsa_port_phylink_mac_link_down(struct phylink_config *config,
}
static void dsa_port_phylink_mac_link_up(struct phylink_config *config,
+ struct phy_device *phydev,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct dsa_port *dp = container_of(config, struct dsa_port, pl_config);
struct dsa_switch *ds = dp->ds;
--
2.20.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 10:23 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Ioana Radulescu, Jonathan Corbet, Michal Simek, Jose Abreu,
Jakub Kicinski, Mark Lee, Sean Wang, Alexandre Torgue,
Hauke Mehrtens, Radhey Shyam Pandey, linux-mediatek,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
linux-arm-kernel, netdev, Nicolas Ferre, Vivien Didelot,
Maxime Coquelin, Vladimir Oltean, David S. Miller, Felix Fietkau
Propagate the resolved link parameters via the mac_link_up() call for
MACs that do not automatically track their PCS state. We propagate the
link parameters via function arguments so that inappropriate members
of struct phylink_link_state can't be accessed, and creating a new
structure just for this adds needless complexity to the API.
Tested-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
Documentation/networking/sfp-phylink.rst | 17 +++++-
drivers/net/ethernet/cadence/macb_main.c | 7 ++-
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
drivers/net/ethernet/marvell/mvneta.c | 8 ++-
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
.../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
drivers/net/phy/phylink.c | 9 ++-
include/linux/phylink.h | 57 ++++++++++++++-----
net/dsa/port.c | 4 +-
11 files changed, 105 insertions(+), 41 deletions(-)
diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
index d753a309f9d1..8d7af28cd835 100644
--- a/Documentation/networking/sfp-phylink.rst
+++ b/Documentation/networking/sfp-phylink.rst
@@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
this documentation.
1. Optionally split the network driver's phylib update function into
- three parts dealing with link-down, link-up and reconfiguring the
- MAC settings. This can be done as a separate preparation commit.
+ two parts dealing with link-down and link-up. This can be done as
+ a separate preparation commit.
- An example of this preparation can be found in git commit fc548b991fb0.
+ An older example of this preparation can be found in git commit
+ fc548b991fb0, although this was splitting into three parts; the
+ link-up part now includes configuring the MAC for the link settings.
+ Please see :c:func:`mac_link_up` for more information on this.
2. Replace::
@@ -207,6 +210,14 @@ this documentation.
using. This is particularly important for in-band negotiation
methods such as 1000base-X and SGMII.
+ The :c:func:`mac_link_up` method is used to inform the MAC that the
+ link has come up. The call includes the negotiation mode and interface
+ for reference only. The finalised link parameters are also supplied
+ (speed, duplex and flow control/pause enablement settings) which
+ should be used to configure the MAC when the MAC and PCS are not
+ tightly integrated, or when the settings are not coming from in-band
+ negotiation.
+
The :c:func:`mac_config` method is used to update the MAC with the
requested state, and must avoid unnecessarily taking the link down
when making changes to the MAC configuration. This means the
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 2c28da1737fe..7ab0bef5e1bd 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -626,8 +626,11 @@ static void macb_mac_link_down(struct phylink_config *config, unsigned int mode,
netif_tx_stop_all_queues(ndev);
}
-static void macb_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy)
+static void macb_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *ndev = to_net_dev(config->dev);
struct macb *bp = netdev_priv(ndev);
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
index 84233e467ed1..3a75c5b58f95 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
@@ -154,8 +154,11 @@ static void dpaa2_mac_config(struct phylink_config *config, unsigned int mode,
netdev_err(mac->net_dev, "dpmac_set_link_state() = %d\n", err);
}
-static void dpaa2_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy)
+static void dpaa2_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct dpaa2_mac *mac = phylink_to_dpaa2_mac(config);
struct dpmac_link_state *dpmac_state = &mac->state;
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 1c391f63a26f..9af3f8d5b289 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3965,9 +3965,11 @@ static void mvneta_mac_link_down(struct phylink_config *config,
mvneta_set_eee(pp, false);
}
-static void mvneta_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy)
+static void mvneta_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *ndev = to_net_dev(config->dev);
struct mvneta_port *pp = netdev_priv(ndev);
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 72133cbe55d4..ed8042d97e29 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -58,8 +58,11 @@ static struct {
*/
static void mvpp2_mac_config(struct phylink_config *config, unsigned int mode,
const struct phylink_link_state *state);
-static void mvpp2_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy);
+static void mvpp2_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause);
/* Queue modes */
#define MVPP2_QDIST_SINGLE_MODE 0
@@ -3473,8 +3476,9 @@ static void mvpp2_start_dev(struct mvpp2_port *port)
.interface = port->phy_interface,
};
mvpp2_mac_config(&port->phylink_config, MLO_AN_INBAND, &state);
- mvpp2_mac_link_up(&port->phylink_config, MLO_AN_INBAND,
- port->phy_interface, NULL);
+ mvpp2_mac_link_up(&port->phylink_config, NULL,
+ MLO_AN_INBAND, port->phy_interface,
+ SPEED_UNKNOWN, DUPLEX_UNKNOWN, false, false);
}
netif_tx_start_all_queues(port->dev);
@@ -5141,8 +5145,11 @@ static void mvpp2_mac_config(struct phylink_config *config, unsigned int mode,
mvpp2_port_enable(port);
}
-static void mvpp2_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy)
+static void mvpp2_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *dev = to_net_dev(config->dev);
struct mvpp2_port *port = netdev_priv(dev);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8c6cfd15481c..8d28f90acfe7 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -412,9 +412,10 @@ static void mtk_mac_link_down(struct phylink_config *config, unsigned int mode,
mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id));
}
-static void mtk_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy)
+static void mtk_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex, bool tx_pause, bool rx_pause)
{
struct mtk_mac *mac = container_of(config, struct mtk_mac,
phylink_config);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 37920b4da091..e039e715dcee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -950,8 +950,10 @@ static void stmmac_mac_link_down(struct phylink_config *config,
}
static void stmmac_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
unsigned int mode, phy_interface_t interface,
- struct phy_device *phy)
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 20746b801959..197740781157 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1486,9 +1486,10 @@ static void axienet_mac_link_down(struct phylink_config *config,
}
static void axienet_mac_link_up(struct phylink_config *config,
- unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy)
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
/* nothing meaningful to do */
}
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 2899fbe699ab..b4367fab7899 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -480,8 +480,11 @@ static void phylink_mac_link_up(struct phylink *pl,
struct net_device *ndev = pl->netdev;
pl->cur_interface = link_state.interface;
- pl->ops->mac_link_up(pl->config, pl->cur_link_an_mode,
- pl->cur_interface, pl->phydev);
+ pl->ops->mac_link_up(pl->config, pl->phydev,
+ pl->cur_link_an_mode, pl->cur_interface,
+ link_state.speed, link_state.duplex,
+ !!(link_state.pause & MLO_PAUSE_TX),
+ !!(link_state.pause & MLO_PAUSE_RX));
if (ndev)
netif_carrier_on(ndev);
@@ -547,6 +550,8 @@ static void phylink_resolve(struct work_struct *w)
link_state.pause = pl->phy_state.pause;
phylink_apply_manual_flow(pl, &link_state);
phylink_mac_config(pl, &link_state);
+ } else {
+ phylink_apply_manual_flow(pl, &link_state);
}
break;
}
diff --git a/include/linux/phylink.h b/include/linux/phylink.h
index 812357c03df4..2180eb1aa254 100644
--- a/include/linux/phylink.h
+++ b/include/linux/phylink.h
@@ -91,9 +91,10 @@ struct phylink_mac_ops {
void (*mac_an_restart)(struct phylink_config *config);
void (*mac_link_down)(struct phylink_config *config, unsigned int mode,
phy_interface_t interface);
- void (*mac_link_up)(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy);
+ void (*mac_link_up)(struct phylink_config *config,
+ struct phy_device *phy, unsigned int mode,
+ phy_interface_t interface, int speed, int duplex,
+ bool tx_pause, bool rx_pause);
};
#if 0 /* For kernel-doc purposes only. */
@@ -152,6 +153,9 @@ void mac_pcs_get_state(struct phylink_config *config,
* guaranteed to be correct, and so any mac_config() implementation must
* never reference these fields.
*
+ * (this requires a rewrite - please refer to mac_link_up() for situations
+ * where the PCS and MAC are not tightly integrated.)
+ *
* In all negotiation modes, as defined by @mode, @state->pause indicates the
* pause settings which should be applied as follows. If %MLO_PAUSE_AN is not
* set, %MLO_PAUSE_TX and %MLO_PAUSE_RX indicate whether the MAC should send
@@ -162,12 +166,20 @@ void mac_pcs_get_state(struct phylink_config *config,
* The action performed depends on the currently selected mode:
*
* %MLO_AN_FIXED, %MLO_AN_PHY:
- * Configure the specified @state->speed and @state->duplex over a link
- * specified by @state->interface. @state->advertising may be used, but
- * is not required. Pause modes as above. Other members of @state must
- * be ignored.
+ * Configure for non-inband negotiation mode, where the link settings
+ * are completely communicated via mac_link_up(). The physical link
+ * protocol from the MAC is specified by @state->interface.
+ *
+ * @state->advertising may be used, but is not required.
+ *
+ * Older drivers (prior to the mac_link_up() change) may use @state->speed,
+ * @state->duplex and @state->pause to configure the MAC, but this is
+ * deprecated; such drivers should be converted to use mac_link_up().
*
- * Valid state members: interface, speed, duplex, pause, advertising.
+ * Other members of @state must be ignored.
+ *
+ * Valid state members: interface, advertising.
+ * Deprecated state members: speed, duplex, pause.
*
* %MLO_AN_INBAND:
* place the link in an inband negotiation mode (such as 802.3z
@@ -228,19 +240,34 @@ void mac_link_down(struct phylink_config *config, unsigned int mode,
/**
* mac_link_up() - allow the link to come up
* @config: a pointer to a &struct phylink_config.
+ * @phy: any attached phy
* @mode: link autonegotiation mode
* @interface: link &typedef phy_interface_t mode
- * @phy: any attached phy
+ * @speed: link speed
+ * @duplex: link duplex
+ * @tx_pause: link transmit pause enablement status
+ * @rx_pause: link receive pause enablement status
*
- * If @mode is not an in-band negotiation mode (as defined by
- * phylink_autoneg_inband()), allow the link to come up. If @phy
- * is non-%NULL, configure Energy Efficient Ethernet by calling
+ * Configure the MAC for an established link.
+ *
+ * @speed, @duplex, @tx_pause and @rx_pause indicate the finalised link
+ * settings, and should be used to configure the MAC block appropriately
+ * where these settings are not automatically conveyed from the PCS block,
+ * or if in-band negotiation (as defined by phylink_autoneg_inband(@mode))
+ * is disabled.
+ *
+ * Note that when 802.3z in-band negotiation is in use, it is possible
+ * that the user wishes to override the pause settings, and this should
+ * be allowed when considering the implementation of this method.
+ *
+ * If in-band negotiation mode is disabled, allow the link to come up. If
+ * @phy is non-%NULL, configure Energy Efficient Ethernet by calling
* phy_init_eee() and perform appropriate MAC configuration for EEE.
* Interface type selection must be done in mac_config().
*/
-void mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy);
+void mac_link_up(struct phylink_config *config, struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex, bool tx_pause, bool rx_pause);
#endif
struct phylink *phylink_create(struct phylink_config *, struct fwnode_handle *,
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 774facb8d547..b2f5262b35cf 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -489,9 +489,11 @@ static void dsa_port_phylink_mac_link_down(struct phylink_config *config,
}
static void dsa_port_phylink_mac_link_up(struct phylink_config *config,
+ struct phy_device *phydev,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct dsa_port *dp = container_of(config, struct dsa_port, pl_config);
struct dsa_switch *ds = dp->ds;
--
2.20.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 10:23 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Ioana Radulescu, Jonathan Corbet, Michal Simek, Jose Abreu,
Jakub Kicinski, Mark Lee, Sean Wang, Alexandre Torgue,
Hauke Mehrtens, Radhey Shyam Pandey, linux-mediatek,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
linux-arm-kernel, netdev, Vivien Didelot, Maxime Coquelin,
Vladimir Oltean, David S. Miller, Felix Fietkau
Propagate the resolved link parameters via the mac_link_up() call for
MACs that do not automatically track their PCS state. We propagate the
link parameters via function arguments so that inappropriate members
of struct phylink_link_state can't be accessed, and creating a new
structure just for this adds needless complexity to the API.
Tested-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
Documentation/networking/sfp-phylink.rst | 17 +++++-
drivers/net/ethernet/cadence/macb_main.c | 7 ++-
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
drivers/net/ethernet/marvell/mvneta.c | 8 ++-
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
.../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
drivers/net/phy/phylink.c | 9 ++-
include/linux/phylink.h | 57 ++++++++++++++-----
net/dsa/port.c | 4 +-
11 files changed, 105 insertions(+), 41 deletions(-)
diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
index d753a309f9d1..8d7af28cd835 100644
--- a/Documentation/networking/sfp-phylink.rst
+++ b/Documentation/networking/sfp-phylink.rst
@@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
this documentation.
1. Optionally split the network driver's phylib update function into
- three parts dealing with link-down, link-up and reconfiguring the
- MAC settings. This can be done as a separate preparation commit.
+ two parts dealing with link-down and link-up. This can be done as
+ a separate preparation commit.
- An example of this preparation can be found in git commit fc548b991fb0.
+ An older example of this preparation can be found in git commit
+ fc548b991fb0, although this was splitting into three parts; the
+ link-up part now includes configuring the MAC for the link settings.
+ Please see :c:func:`mac_link_up` for more information on this.
2. Replace::
@@ -207,6 +210,14 @@ this documentation.
using. This is particularly important for in-band negotiation
methods such as 1000base-X and SGMII.
+ The :c:func:`mac_link_up` method is used to inform the MAC that the
+ link has come up. The call includes the negotiation mode and interface
+ for reference only. The finalised link parameters are also supplied
+ (speed, duplex and flow control/pause enablement settings) which
+ should be used to configure the MAC when the MAC and PCS are not
+ tightly integrated, or when the settings are not coming from in-band
+ negotiation.
+
The :c:func:`mac_config` method is used to update the MAC with the
requested state, and must avoid unnecessarily taking the link down
when making changes to the MAC configuration. This means the
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 2c28da1737fe..7ab0bef5e1bd 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -626,8 +626,11 @@ static void macb_mac_link_down(struct phylink_config *config, unsigned int mode,
netif_tx_stop_all_queues(ndev);
}
-static void macb_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy)
+static void macb_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *ndev = to_net_dev(config->dev);
struct macb *bp = netdev_priv(ndev);
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
index 84233e467ed1..3a75c5b58f95 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
@@ -154,8 +154,11 @@ static void dpaa2_mac_config(struct phylink_config *config, unsigned int mode,
netdev_err(mac->net_dev, "dpmac_set_link_state() = %d\n", err);
}
-static void dpaa2_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy)
+static void dpaa2_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct dpaa2_mac *mac = phylink_to_dpaa2_mac(config);
struct dpmac_link_state *dpmac_state = &mac->state;
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 1c391f63a26f..9af3f8d5b289 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3965,9 +3965,11 @@ static void mvneta_mac_link_down(struct phylink_config *config,
mvneta_set_eee(pp, false);
}
-static void mvneta_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy)
+static void mvneta_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *ndev = to_net_dev(config->dev);
struct mvneta_port *pp = netdev_priv(ndev);
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 72133cbe55d4..ed8042d97e29 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -58,8 +58,11 @@ static struct {
*/
static void mvpp2_mac_config(struct phylink_config *config, unsigned int mode,
const struct phylink_link_state *state);
-static void mvpp2_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy);
+static void mvpp2_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause);
/* Queue modes */
#define MVPP2_QDIST_SINGLE_MODE 0
@@ -3473,8 +3476,9 @@ static void mvpp2_start_dev(struct mvpp2_port *port)
.interface = port->phy_interface,
};
mvpp2_mac_config(&port->phylink_config, MLO_AN_INBAND, &state);
- mvpp2_mac_link_up(&port->phylink_config, MLO_AN_INBAND,
- port->phy_interface, NULL);
+ mvpp2_mac_link_up(&port->phylink_config, NULL,
+ MLO_AN_INBAND, port->phy_interface,
+ SPEED_UNKNOWN, DUPLEX_UNKNOWN, false, false);
}
netif_tx_start_all_queues(port->dev);
@@ -5141,8 +5145,11 @@ static void mvpp2_mac_config(struct phylink_config *config, unsigned int mode,
mvpp2_port_enable(port);
}
-static void mvpp2_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface, struct phy_device *phy)
+static void mvpp2_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *dev = to_net_dev(config->dev);
struct mvpp2_port *port = netdev_priv(dev);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8c6cfd15481c..8d28f90acfe7 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -412,9 +412,10 @@ static void mtk_mac_link_down(struct phylink_config *config, unsigned int mode,
mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id));
}
-static void mtk_mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy)
+static void mtk_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex, bool tx_pause, bool rx_pause)
{
struct mtk_mac *mac = container_of(config, struct mtk_mac,
phylink_config);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 37920b4da091..e039e715dcee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -950,8 +950,10 @@ static void stmmac_mac_link_down(struct phylink_config *config,
}
static void stmmac_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
unsigned int mode, phy_interface_t interface,
- struct phy_device *phy)
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 20746b801959..197740781157 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1486,9 +1486,10 @@ static void axienet_mac_link_down(struct phylink_config *config,
}
static void axienet_mac_link_up(struct phylink_config *config,
- unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy)
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
/* nothing meaningful to do */
}
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 2899fbe699ab..b4367fab7899 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -480,8 +480,11 @@ static void phylink_mac_link_up(struct phylink *pl,
struct net_device *ndev = pl->netdev;
pl->cur_interface = link_state.interface;
- pl->ops->mac_link_up(pl->config, pl->cur_link_an_mode,
- pl->cur_interface, pl->phydev);
+ pl->ops->mac_link_up(pl->config, pl->phydev,
+ pl->cur_link_an_mode, pl->cur_interface,
+ link_state.speed, link_state.duplex,
+ !!(link_state.pause & MLO_PAUSE_TX),
+ !!(link_state.pause & MLO_PAUSE_RX));
if (ndev)
netif_carrier_on(ndev);
@@ -547,6 +550,8 @@ static void phylink_resolve(struct work_struct *w)
link_state.pause = pl->phy_state.pause;
phylink_apply_manual_flow(pl, &link_state);
phylink_mac_config(pl, &link_state);
+ } else {
+ phylink_apply_manual_flow(pl, &link_state);
}
break;
}
diff --git a/include/linux/phylink.h b/include/linux/phylink.h
index 812357c03df4..2180eb1aa254 100644
--- a/include/linux/phylink.h
+++ b/include/linux/phylink.h
@@ -91,9 +91,10 @@ struct phylink_mac_ops {
void (*mac_an_restart)(struct phylink_config *config);
void (*mac_link_down)(struct phylink_config *config, unsigned int mode,
phy_interface_t interface);
- void (*mac_link_up)(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy);
+ void (*mac_link_up)(struct phylink_config *config,
+ struct phy_device *phy, unsigned int mode,
+ phy_interface_t interface, int speed, int duplex,
+ bool tx_pause, bool rx_pause);
};
#if 0 /* For kernel-doc purposes only. */
@@ -152,6 +153,9 @@ void mac_pcs_get_state(struct phylink_config *config,
* guaranteed to be correct, and so any mac_config() implementation must
* never reference these fields.
*
+ * (this requires a rewrite - please refer to mac_link_up() for situations
+ * where the PCS and MAC are not tightly integrated.)
+ *
* In all negotiation modes, as defined by @mode, @state->pause indicates the
* pause settings which should be applied as follows. If %MLO_PAUSE_AN is not
* set, %MLO_PAUSE_TX and %MLO_PAUSE_RX indicate whether the MAC should send
@@ -162,12 +166,20 @@ void mac_pcs_get_state(struct phylink_config *config,
* The action performed depends on the currently selected mode:
*
* %MLO_AN_FIXED, %MLO_AN_PHY:
- * Configure the specified @state->speed and @state->duplex over a link
- * specified by @state->interface. @state->advertising may be used, but
- * is not required. Pause modes as above. Other members of @state must
- * be ignored.
+ * Configure for non-inband negotiation mode, where the link settings
+ * are completely communicated via mac_link_up(). The physical link
+ * protocol from the MAC is specified by @state->interface.
+ *
+ * @state->advertising may be used, but is not required.
+ *
+ * Older drivers (prior to the mac_link_up() change) may use @state->speed,
+ * @state->duplex and @state->pause to configure the MAC, but this is
+ * deprecated; such drivers should be converted to use mac_link_up().
*
- * Valid state members: interface, speed, duplex, pause, advertising.
+ * Other members of @state must be ignored.
+ *
+ * Valid state members: interface, advertising.
+ * Deprecated state members: speed, duplex, pause.
*
* %MLO_AN_INBAND:
* place the link in an inband negotiation mode (such as 802.3z
@@ -228,19 +240,34 @@ void mac_link_down(struct phylink_config *config, unsigned int mode,
/**
* mac_link_up() - allow the link to come up
* @config: a pointer to a &struct phylink_config.
+ * @phy: any attached phy
* @mode: link autonegotiation mode
* @interface: link &typedef phy_interface_t mode
- * @phy: any attached phy
+ * @speed: link speed
+ * @duplex: link duplex
+ * @tx_pause: link transmit pause enablement status
+ * @rx_pause: link receive pause enablement status
*
- * If @mode is not an in-band negotiation mode (as defined by
- * phylink_autoneg_inband()), allow the link to come up. If @phy
- * is non-%NULL, configure Energy Efficient Ethernet by calling
+ * Configure the MAC for an established link.
+ *
+ * @speed, @duplex, @tx_pause and @rx_pause indicate the finalised link
+ * settings, and should be used to configure the MAC block appropriately
+ * where these settings are not automatically conveyed from the PCS block,
+ * or if in-band negotiation (as defined by phylink_autoneg_inband(@mode))
+ * is disabled.
+ *
+ * Note that when 802.3z in-band negotiation is in use, it is possible
+ * that the user wishes to override the pause settings, and this should
+ * be allowed when considering the implementation of this method.
+ *
+ * If in-band negotiation mode is disabled, allow the link to come up. If
+ * @phy is non-%NULL, configure Energy Efficient Ethernet by calling
* phy_init_eee() and perform appropriate MAC configuration for EEE.
* Interface type selection must be done in mac_config().
*/
-void mac_link_up(struct phylink_config *config, unsigned int mode,
- phy_interface_t interface,
- struct phy_device *phy);
+void mac_link_up(struct phylink_config *config, struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex, bool tx_pause, bool rx_pause);
#endif
struct phylink *phylink_create(struct phylink_config *, struct fwnode_handle *,
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 774facb8d547..b2f5262b35cf 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -489,9 +489,11 @@ static void dsa_port_phylink_mac_link_down(struct phylink_config *config,
}
static void dsa_port_phylink_mac_link_up(struct phylink_config *config,
+ struct phy_device *phydev,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct dsa_port *dp = container_of(config, struct dsa_port, pl_config);
struct dsa_switch *ds = dp->ds;
--
2.20.1
_______________________________________________
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] 60+ messages in thread
* [PATCH net-next v2 2/8] net: dsa: propagate resolved link config via mac_link_up()
2020-02-26 10:23 ` Russell King - ARM Linux admin
(?)
@ 2020-02-26 10:23 ` Russell King
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: Alexandre Torgue, David S. Miller, Felix Fietkau,
Giuseppe Cavallaro, Hauke Mehrtens, Ioana Ciornei,
Jakub Kicinski, John Crispin, Jonathan Corbet, Jose Abreu,
linux-arm-kernel, linux-doc, linux-mediatek, linux-stm32,
Mark Lee, Matthias Brugger, Maxime Coquelin, Michal Simek,
netdev, Nicolas Ferre, Radhey Shyam Pandey, Sean Wang,
Thomas Petazzoni, Vivien Didelot, Vladimir Oltean,
Vladimir Oltean, Claudiu Manoil
Propagate the resolved link configuration down via DSA's
phylink_mac_link_up() operation to allow split PCS/MAC to work.
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/dsa/b53/b53_common.c | 4 +++-
drivers/net/dsa/b53/b53_priv.h | 4 +++-
drivers/net/dsa/bcm_sf2.c | 4 +++-
drivers/net/dsa/lantiq_gswip.c | 4 +++-
drivers/net/dsa/mt7530.c | 4 +++-
drivers/net/dsa/mv88e6xxx/chip.c | 4 +++-
drivers/net/dsa/ocelot/felix.c | 4 +++-
drivers/net/dsa/qca/ar9331.c | 4 +++-
drivers/net/dsa/sja1105/sja1105_main.c | 4 +++-
include/net/dsa.h | 4 +++-
net/dsa/port.c | 3 ++-
11 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 1a69286daa8d..ceafce446317 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1289,7 +1289,9 @@ EXPORT_SYMBOL(b53_phylink_mac_link_down);
void b53_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct b53_device *dev = ds->priv;
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index 3c30f3a7eb29..3d42318bc3f1 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -338,7 +338,9 @@ void b53_phylink_mac_link_down(struct dsa_switch *ds, int port,
void b53_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev);
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause);
int b53_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering);
int b53_vlan_prepare(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan);
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 6feaf8cb0809..a1110133dadf 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -652,7 +652,9 @@ static void bcm_sf2_sw_mac_link_down(struct dsa_switch *ds, int port,
static void bcm_sf2_sw_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
struct ethtool_eee *p = &priv->dev->ports[port].eee;
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 0369c22fe3e1..cf6fa8fede33 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -1517,7 +1517,9 @@ static void gswip_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void gswip_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct gswip_priv *priv = ds->priv;
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 022466ca1c19..86818ab3bb07 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1482,7 +1482,9 @@ static void mt7530_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void mt7530_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct mt7530_priv *priv = ds->priv;
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 4ec09cc8dcdc..fef3b5e0b291 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -655,7 +655,9 @@ static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port,
static void mv88e6xxx_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode, phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
if (mode == MLO_AN_FIXED)
mv88e6xxx_mac_link_force(ds, port, LINK_FORCED_UP);
diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index 35124ef7e75b..7e66821b05b4 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -263,7 +263,9 @@ static void felix_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void felix_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int link_an_mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct ocelot *ocelot = ds->priv;
struct ocelot_port *ocelot_port = ocelot->ports[port];
diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index de25f99e995a..7c86056b9401 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -458,7 +458,9 @@ static void ar9331_sw_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void ar9331_sw_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
struct regmap *regmap = priv->regmap;
diff --git a/drivers/net/dsa/sja1105/sja1105_main.c b/drivers/net/dsa/sja1105/sja1105_main.c
index 03ba6d25f7fe..c27cc7b37440 100644
--- a/drivers/net/dsa/sja1105/sja1105_main.c
+++ b/drivers/net/dsa/sja1105/sja1105_main.c
@@ -786,7 +786,9 @@ static void sja1105_mac_link_down(struct dsa_switch *ds, int port,
static void sja1105_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
sja1105_inhibit_tx(ds->priv, BIT(port), false);
}
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 63495e3443ac..7d3d84f0ef42 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -420,7 +420,9 @@ struct dsa_switch_ops {
void (*phylink_mac_link_up)(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev);
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause);
void (*phylink_fixed_state)(struct dsa_switch *ds, int port,
struct phylink_link_state *state);
/*
diff --git a/net/dsa/port.c b/net/dsa/port.c
index b2f5262b35cf..d4450a454249 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -504,7 +504,8 @@ static void dsa_port_phylink_mac_link_up(struct phylink_config *config,
return;
}
- ds->ops->phylink_mac_link_up(ds, dp->index, mode, interface, phydev);
+ ds->ops->phylink_mac_link_up(ds, dp->index, mode, interface, phydev,
+ speed, duplex, tx_pause, rx_pause);
}
const struct phylink_mac_ops dsa_port_phylink_mac_ops = {
--
2.20.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 2/8] net: dsa: propagate resolved link config via mac_link_up()
@ 2020-02-26 10:23 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Vladimir Oltean, Thomas Petazzoni, Ioana Ciornei,
linux-stm32, Jonathan Corbet, Michal Simek, Jose Abreu,
Jakub Kicinski, Mark Lee, Sean Wang, Alexandre Torgue,
Hauke Mehrtens, Radhey Shyam Pandey, Claudiu Manoil,
linux-mediatek, John Crispin, Matthias Brugger,
Giuseppe Cavallaro, linux-arm-kernel, netdev, Nicolas Ferre,
Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Propagate the resolved link configuration down via DSA's
phylink_mac_link_up() operation to allow split PCS/MAC to work.
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/dsa/b53/b53_common.c | 4 +++-
drivers/net/dsa/b53/b53_priv.h | 4 +++-
drivers/net/dsa/bcm_sf2.c | 4 +++-
drivers/net/dsa/lantiq_gswip.c | 4 +++-
drivers/net/dsa/mt7530.c | 4 +++-
drivers/net/dsa/mv88e6xxx/chip.c | 4 +++-
drivers/net/dsa/ocelot/felix.c | 4 +++-
drivers/net/dsa/qca/ar9331.c | 4 +++-
drivers/net/dsa/sja1105/sja1105_main.c | 4 +++-
include/net/dsa.h | 4 +++-
net/dsa/port.c | 3 ++-
11 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 1a69286daa8d..ceafce446317 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1289,7 +1289,9 @@ EXPORT_SYMBOL(b53_phylink_mac_link_down);
void b53_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct b53_device *dev = ds->priv;
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index 3c30f3a7eb29..3d42318bc3f1 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -338,7 +338,9 @@ void b53_phylink_mac_link_down(struct dsa_switch *ds, int port,
void b53_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev);
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause);
int b53_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering);
int b53_vlan_prepare(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan);
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 6feaf8cb0809..a1110133dadf 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -652,7 +652,9 @@ static void bcm_sf2_sw_mac_link_down(struct dsa_switch *ds, int port,
static void bcm_sf2_sw_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
struct ethtool_eee *p = &priv->dev->ports[port].eee;
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 0369c22fe3e1..cf6fa8fede33 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -1517,7 +1517,9 @@ static void gswip_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void gswip_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct gswip_priv *priv = ds->priv;
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 022466ca1c19..86818ab3bb07 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1482,7 +1482,9 @@ static void mt7530_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void mt7530_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct mt7530_priv *priv = ds->priv;
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 4ec09cc8dcdc..fef3b5e0b291 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -655,7 +655,9 @@ static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port,
static void mv88e6xxx_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode, phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
if (mode == MLO_AN_FIXED)
mv88e6xxx_mac_link_force(ds, port, LINK_FORCED_UP);
diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index 35124ef7e75b..7e66821b05b4 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -263,7 +263,9 @@ static void felix_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void felix_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int link_an_mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct ocelot *ocelot = ds->priv;
struct ocelot_port *ocelot_port = ocelot->ports[port];
diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index de25f99e995a..7c86056b9401 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -458,7 +458,9 @@ static void ar9331_sw_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void ar9331_sw_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
struct regmap *regmap = priv->regmap;
diff --git a/drivers/net/dsa/sja1105/sja1105_main.c b/drivers/net/dsa/sja1105/sja1105_main.c
index 03ba6d25f7fe..c27cc7b37440 100644
--- a/drivers/net/dsa/sja1105/sja1105_main.c
+++ b/drivers/net/dsa/sja1105/sja1105_main.c
@@ -786,7 +786,9 @@ static void sja1105_mac_link_down(struct dsa_switch *ds, int port,
static void sja1105_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
sja1105_inhibit_tx(ds->priv, BIT(port), false);
}
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 63495e3443ac..7d3d84f0ef42 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -420,7 +420,9 @@ struct dsa_switch_ops {
void (*phylink_mac_link_up)(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev);
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause);
void (*phylink_fixed_state)(struct dsa_switch *ds, int port,
struct phylink_link_state *state);
/*
diff --git a/net/dsa/port.c b/net/dsa/port.c
index b2f5262b35cf..d4450a454249 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -504,7 +504,8 @@ static void dsa_port_phylink_mac_link_up(struct phylink_config *config,
return;
}
- ds->ops->phylink_mac_link_up(ds, dp->index, mode, interface, phydev);
+ ds->ops->phylink_mac_link_up(ds, dp->index, mode, interface, phydev,
+ speed, duplex, tx_pause, rx_pause);
}
const struct phylink_mac_ops dsa_port_phylink_mac_ops = {
--
2.20.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 2/8] net: dsa: propagate resolved link config via mac_link_up()
@ 2020-02-26 10:23 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Vladimir Oltean, Thomas Petazzoni, Ioana Ciornei,
linux-stm32, Jonathan Corbet, Michal Simek, Jose Abreu,
Jakub Kicinski, Mark Lee, Sean Wang, Alexandre Torgue,
Hauke Mehrtens, Radhey Shyam Pandey, Claudiu Manoil,
linux-mediatek, John Crispin, Matthias Brugger,
Giuseppe Cavallaro, linux-arm-kernel, netdev, Vivien Didelot,
Maxime Coquelin, Vladimir Oltean, David S. Miller, Felix Fietkau
Propagate the resolved link configuration down via DSA's
phylink_mac_link_up() operation to allow split PCS/MAC to work.
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/dsa/b53/b53_common.c | 4 +++-
drivers/net/dsa/b53/b53_priv.h | 4 +++-
drivers/net/dsa/bcm_sf2.c | 4 +++-
drivers/net/dsa/lantiq_gswip.c | 4 +++-
drivers/net/dsa/mt7530.c | 4 +++-
drivers/net/dsa/mv88e6xxx/chip.c | 4 +++-
drivers/net/dsa/ocelot/felix.c | 4 +++-
drivers/net/dsa/qca/ar9331.c | 4 +++-
drivers/net/dsa/sja1105/sja1105_main.c | 4 +++-
include/net/dsa.h | 4 +++-
net/dsa/port.c | 3 ++-
11 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 1a69286daa8d..ceafce446317 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1289,7 +1289,9 @@ EXPORT_SYMBOL(b53_phylink_mac_link_down);
void b53_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct b53_device *dev = ds->priv;
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index 3c30f3a7eb29..3d42318bc3f1 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -338,7 +338,9 @@ void b53_phylink_mac_link_down(struct dsa_switch *ds, int port,
void b53_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev);
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause);
int b53_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering);
int b53_vlan_prepare(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan);
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 6feaf8cb0809..a1110133dadf 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -652,7 +652,9 @@ static void bcm_sf2_sw_mac_link_down(struct dsa_switch *ds, int port,
static void bcm_sf2_sw_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
struct ethtool_eee *p = &priv->dev->ports[port].eee;
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 0369c22fe3e1..cf6fa8fede33 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -1517,7 +1517,9 @@ static void gswip_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void gswip_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct gswip_priv *priv = ds->priv;
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 022466ca1c19..86818ab3bb07 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1482,7 +1482,9 @@ static void mt7530_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void mt7530_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct mt7530_priv *priv = ds->priv;
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 4ec09cc8dcdc..fef3b5e0b291 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -655,7 +655,9 @@ static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port,
static void mv88e6xxx_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode, phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
if (mode == MLO_AN_FIXED)
mv88e6xxx_mac_link_force(ds, port, LINK_FORCED_UP);
diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index 35124ef7e75b..7e66821b05b4 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -263,7 +263,9 @@ static void felix_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void felix_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int link_an_mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct ocelot *ocelot = ds->priv;
struct ocelot_port *ocelot_port = ocelot->ports[port];
diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index de25f99e995a..7c86056b9401 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -458,7 +458,9 @@ static void ar9331_sw_phylink_mac_link_down(struct dsa_switch *ds, int port,
static void ar9331_sw_phylink_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
struct regmap *regmap = priv->regmap;
diff --git a/drivers/net/dsa/sja1105/sja1105_main.c b/drivers/net/dsa/sja1105/sja1105_main.c
index 03ba6d25f7fe..c27cc7b37440 100644
--- a/drivers/net/dsa/sja1105/sja1105_main.c
+++ b/drivers/net/dsa/sja1105/sja1105_main.c
@@ -786,7 +786,9 @@ static void sja1105_mac_link_down(struct dsa_switch *ds, int port,
static void sja1105_mac_link_up(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev)
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
sja1105_inhibit_tx(ds->priv, BIT(port), false);
}
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 63495e3443ac..7d3d84f0ef42 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -420,7 +420,9 @@ struct dsa_switch_ops {
void (*phylink_mac_link_up)(struct dsa_switch *ds, int port,
unsigned int mode,
phy_interface_t interface,
- struct phy_device *phydev);
+ struct phy_device *phydev,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause);
void (*phylink_fixed_state)(struct dsa_switch *ds, int port,
struct phylink_link_state *state);
/*
diff --git a/net/dsa/port.c b/net/dsa/port.c
index b2f5262b35cf..d4450a454249 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -504,7 +504,8 @@ static void dsa_port_phylink_mac_link_up(struct phylink_config *config,
return;
}
- ds->ops->phylink_mac_link_up(ds, dp->index, mode, interface, phydev);
+ ds->ops->phylink_mac_link_up(ds, dp->index, mode, interface, phydev,
+ speed, duplex, tx_pause, rx_pause);
}
const struct phylink_mac_ops dsa_port_phylink_mac_ops = {
--
2.20.1
_______________________________________________
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] 60+ messages in thread
* [PATCH net-next v2 3/8] net: mv88e6xxx: use resolved link config in mac_link_up()
2020-02-26 10:23 ` Russell King - ARM Linux admin
(?)
@ 2020-02-26 10:23 ` Russell King
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: Alexandre Torgue, David S. Miller, Felix Fietkau,
Giuseppe Cavallaro, Hauke Mehrtens, Ioana Ciornei,
Jakub Kicinski, John Crispin, Jonathan Corbet, Jose Abreu,
linux-arm-kernel, linux-doc, linux-mediatek, linux-stm32,
Mark Lee, Matthias Brugger, Maxime Coquelin, Michal Simek,
netdev, Nicolas Ferre, Radhey Shyam Pandey, Sean Wang,
Thomas Petazzoni, Vivien Didelot, Vladimir Oltean
Use the resolved link configuration to set the MAC configuration when
mac_link_up() for non-internal-PHY ports.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/dsa/mv88e6xxx/chip.c | 75 +++++++++++++++++++++++++-------
1 file changed, 59 insertions(+), 16 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index fef3b5e0b291..4a4173e63fa5 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -632,25 +632,30 @@ static void mv88e6xxx_mac_config(struct dsa_switch *ds, int port,
dev_err(ds->dev, "p%d: failed to configure MAC\n", port);
}
-static void mv88e6xxx_mac_link_force(struct dsa_switch *ds, int port, int link)
+static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port,
+ unsigned int mode,
+ phy_interface_t interface)
{
struct mv88e6xxx_chip *chip = ds->priv;
- int err;
+ const struct mv88e6xxx_ops *ops;
+ int err = 0;
- mv88e6xxx_reg_lock(chip);
- err = chip->info->ops->port_set_link(chip, port, link);
- mv88e6xxx_reg_unlock(chip);
+ ops = chip->info->ops;
- if (err)
- dev_err(chip->dev, "p%d: failed to force MAC link\n", port);
-}
+ /* Internal PHYs propagate their configuration directly to the MAC.
+ * External PHYs depend on whether the PPU is enabled for this port.
+ * FIXME: we should be using the PPU enable state here. What about
+ * an automedia port?
+ */
+ if (!mv88e6xxx_phy_is_internal(ds, port) && ops->port_set_link) {
+ mv88e6xxx_reg_lock(chip);
+ err = ops->port_set_link(chip, port, LINK_FORCED_DOWN);
+ mv88e6xxx_reg_unlock(chip);
-static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port,
- unsigned int mode,
- phy_interface_t interface)
-{
- if (mode == MLO_AN_FIXED)
- mv88e6xxx_mac_link_force(ds, port, LINK_FORCED_DOWN);
+ if (err)
+ dev_err(chip->dev,
+ "p%d: failed to force MAC link down\n", port);
+ }
}
static void mv88e6xxx_mac_link_up(struct dsa_switch *ds, int port,
@@ -659,8 +664,46 @@ static void mv88e6xxx_mac_link_up(struct dsa_switch *ds, int port,
int speed, int duplex,
bool tx_pause, bool rx_pause)
{
- if (mode == MLO_AN_FIXED)
- mv88e6xxx_mac_link_force(ds, port, LINK_FORCED_UP);
+ struct mv88e6xxx_chip *chip = ds->priv;
+ const struct mv88e6xxx_ops *ops;
+ int err = 0;
+
+ ops = chip->info->ops;
+
+ /* Internal PHYs propagate their configuration directly to the MAC.
+ * External PHYs depend on whether the PPU is enabled for this port.
+ * FIXME: we should be using the PPU enable state here. What about
+ * an automedia port?
+ */
+ if (!mv88e6xxx_phy_is_internal(ds, port)) {
+ mv88e6xxx_reg_lock(chip);
+ /* FIXME: for an automedia port, should we force the link
+ * down here - what if the link comes up due to "other" media
+ * while we're bringing the port up, how is the exclusivity
+ * handled in the Marvell hardware? E.g. port 4 on 88E6532
+ * shared between internal PHY and Serdes.
+ */
+ if (ops->port_set_speed) {
+ err = ops->port_set_speed(chip, port, speed);
+ if (err && err != -EOPNOTSUPP)
+ goto error;
+ }
+
+ if (ops->port_set_duplex) {
+ err = ops->port_set_duplex(chip, port, duplex);
+ if (err && err != -EOPNOTSUPP)
+ goto error;
+ }
+
+ if (ops->port_set_link)
+ err = ops->port_set_link(chip, port, LINK_FORCED_UP);
+error:
+ mv88e6xxx_reg_unlock(chip);
+
+ if (err && err != -EOPNOTSUPP)
+ dev_err(ds->dev,
+ "p%d: failed to configure MAC link up\n", port);
+ }
}
static int mv88e6xxx_stats_snapshot(struct mv88e6xxx_chip *chip, int port)
--
2.20.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 3/8] net: mv88e6xxx: use resolved link config in mac_link_up()
@ 2020-02-26 10:23 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Nicolas Ferre, Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Use the resolved link configuration to set the MAC configuration when
mac_link_up() for non-internal-PHY ports.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/dsa/mv88e6xxx/chip.c | 75 +++++++++++++++++++++++++-------
1 file changed, 59 insertions(+), 16 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index fef3b5e0b291..4a4173e63fa5 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -632,25 +632,30 @@ static void mv88e6xxx_mac_config(struct dsa_switch *ds, int port,
dev_err(ds->dev, "p%d: failed to configure MAC\n", port);
}
-static void mv88e6xxx_mac_link_force(struct dsa_switch *ds, int port, int link)
+static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port,
+ unsigned int mode,
+ phy_interface_t interface)
{
struct mv88e6xxx_chip *chip = ds->priv;
- int err;
+ const struct mv88e6xxx_ops *ops;
+ int err = 0;
- mv88e6xxx_reg_lock(chip);
- err = chip->info->ops->port_set_link(chip, port, link);
- mv88e6xxx_reg_unlock(chip);
+ ops = chip->info->ops;
- if (err)
- dev_err(chip->dev, "p%d: failed to force MAC link\n", port);
-}
+ /* Internal PHYs propagate their configuration directly to the MAC.
+ * External PHYs depend on whether the PPU is enabled for this port.
+ * FIXME: we should be using the PPU enable state here. What about
+ * an automedia port?
+ */
+ if (!mv88e6xxx_phy_is_internal(ds, port) && ops->port_set_link) {
+ mv88e6xxx_reg_lock(chip);
+ err = ops->port_set_link(chip, port, LINK_FORCED_DOWN);
+ mv88e6xxx_reg_unlock(chip);
-static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port,
- unsigned int mode,
- phy_interface_t interface)
-{
- if (mode == MLO_AN_FIXED)
- mv88e6xxx_mac_link_force(ds, port, LINK_FORCED_DOWN);
+ if (err)
+ dev_err(chip->dev,
+ "p%d: failed to force MAC link down\n", port);
+ }
}
static void mv88e6xxx_mac_link_up(struct dsa_switch *ds, int port,
@@ -659,8 +664,46 @@ static void mv88e6xxx_mac_link_up(struct dsa_switch *ds, int port,
int speed, int duplex,
bool tx_pause, bool rx_pause)
{
- if (mode == MLO_AN_FIXED)
- mv88e6xxx_mac_link_force(ds, port, LINK_FORCED_UP);
+ struct mv88e6xxx_chip *chip = ds->priv;
+ const struct mv88e6xxx_ops *ops;
+ int err = 0;
+
+ ops = chip->info->ops;
+
+ /* Internal PHYs propagate their configuration directly to the MAC.
+ * External PHYs depend on whether the PPU is enabled for this port.
+ * FIXME: we should be using the PPU enable state here. What about
+ * an automedia port?
+ */
+ if (!mv88e6xxx_phy_is_internal(ds, port)) {
+ mv88e6xxx_reg_lock(chip);
+ /* FIXME: for an automedia port, should we force the link
+ * down here - what if the link comes up due to "other" media
+ * while we're bringing the port up, how is the exclusivity
+ * handled in the Marvell hardware? E.g. port 4 on 88E6532
+ * shared between internal PHY and Serdes.
+ */
+ if (ops->port_set_speed) {
+ err = ops->port_set_speed(chip, port, speed);
+ if (err && err != -EOPNOTSUPP)
+ goto error;
+ }
+
+ if (ops->port_set_duplex) {
+ err = ops->port_set_duplex(chip, port, duplex);
+ if (err && err != -EOPNOTSUPP)
+ goto error;
+ }
+
+ if (ops->port_set_link)
+ err = ops->port_set_link(chip, port, LINK_FORCED_UP);
+error:
+ mv88e6xxx_reg_unlock(chip);
+
+ if (err && err != -EOPNOTSUPP)
+ dev_err(ds->dev,
+ "p%d: failed to configure MAC link up\n", port);
+ }
}
static int mv88e6xxx_stats_snapshot(struct mv88e6xxx_chip *chip, int port)
--
2.20.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 3/8] net: mv88e6xxx: use resolved link config in mac_link_up()
@ 2020-02-26 10:23 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Use the resolved link configuration to set the MAC configuration when
mac_link_up() for non-internal-PHY ports.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/dsa/mv88e6xxx/chip.c | 75 +++++++++++++++++++++++++-------
1 file changed, 59 insertions(+), 16 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index fef3b5e0b291..4a4173e63fa5 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -632,25 +632,30 @@ static void mv88e6xxx_mac_config(struct dsa_switch *ds, int port,
dev_err(ds->dev, "p%d: failed to configure MAC\n", port);
}
-static void mv88e6xxx_mac_link_force(struct dsa_switch *ds, int port, int link)
+static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port,
+ unsigned int mode,
+ phy_interface_t interface)
{
struct mv88e6xxx_chip *chip = ds->priv;
- int err;
+ const struct mv88e6xxx_ops *ops;
+ int err = 0;
- mv88e6xxx_reg_lock(chip);
- err = chip->info->ops->port_set_link(chip, port, link);
- mv88e6xxx_reg_unlock(chip);
+ ops = chip->info->ops;
- if (err)
- dev_err(chip->dev, "p%d: failed to force MAC link\n", port);
-}
+ /* Internal PHYs propagate their configuration directly to the MAC.
+ * External PHYs depend on whether the PPU is enabled for this port.
+ * FIXME: we should be using the PPU enable state here. What about
+ * an automedia port?
+ */
+ if (!mv88e6xxx_phy_is_internal(ds, port) && ops->port_set_link) {
+ mv88e6xxx_reg_lock(chip);
+ err = ops->port_set_link(chip, port, LINK_FORCED_DOWN);
+ mv88e6xxx_reg_unlock(chip);
-static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port,
- unsigned int mode,
- phy_interface_t interface)
-{
- if (mode == MLO_AN_FIXED)
- mv88e6xxx_mac_link_force(ds, port, LINK_FORCED_DOWN);
+ if (err)
+ dev_err(chip->dev,
+ "p%d: failed to force MAC link down\n", port);
+ }
}
static void mv88e6xxx_mac_link_up(struct dsa_switch *ds, int port,
@@ -659,8 +664,46 @@ static void mv88e6xxx_mac_link_up(struct dsa_switch *ds, int port,
int speed, int duplex,
bool tx_pause, bool rx_pause)
{
- if (mode == MLO_AN_FIXED)
- mv88e6xxx_mac_link_force(ds, port, LINK_FORCED_UP);
+ struct mv88e6xxx_chip *chip = ds->priv;
+ const struct mv88e6xxx_ops *ops;
+ int err = 0;
+
+ ops = chip->info->ops;
+
+ /* Internal PHYs propagate their configuration directly to the MAC.
+ * External PHYs depend on whether the PPU is enabled for this port.
+ * FIXME: we should be using the PPU enable state here. What about
+ * an automedia port?
+ */
+ if (!mv88e6xxx_phy_is_internal(ds, port)) {
+ mv88e6xxx_reg_lock(chip);
+ /* FIXME: for an automedia port, should we force the link
+ * down here - what if the link comes up due to "other" media
+ * while we're bringing the port up, how is the exclusivity
+ * handled in the Marvell hardware? E.g. port 4 on 88E6532
+ * shared between internal PHY and Serdes.
+ */
+ if (ops->port_set_speed) {
+ err = ops->port_set_speed(chip, port, speed);
+ if (err && err != -EOPNOTSUPP)
+ goto error;
+ }
+
+ if (ops->port_set_duplex) {
+ err = ops->port_set_duplex(chip, port, duplex);
+ if (err && err != -EOPNOTSUPP)
+ goto error;
+ }
+
+ if (ops->port_set_link)
+ err = ops->port_set_link(chip, port, LINK_FORCED_UP);
+error:
+ mv88e6xxx_reg_unlock(chip);
+
+ if (err && err != -EOPNOTSUPP)
+ dev_err(ds->dev,
+ "p%d: failed to configure MAC link up\n", port);
+ }
}
static int mv88e6xxx_stats_snapshot(struct mv88e6xxx_chip *chip, int port)
--
2.20.1
_______________________________________________
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] 60+ messages in thread
* [PATCH net-next v2 4/8] net: axienet: use resolved link config in mac_link_up()
2020-02-26 10:23 ` Russell King - ARM Linux admin
(?)
@ 2020-02-26 10:23 ` Russell King
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: Alexandre Torgue, David S. Miller, Felix Fietkau,
Giuseppe Cavallaro, Hauke Mehrtens, Ioana Ciornei,
Jakub Kicinski, John Crispin, Jonathan Corbet, Jose Abreu,
linux-arm-kernel, linux-doc, linux-mediatek, linux-stm32,
Mark Lee, Matthias Brugger, Maxime Coquelin, Michal Simek,
netdev, Nicolas Ferre, Radhey Shyam Pandey, Sean Wang,
Thomas Petazzoni, Vivien Didelot, Vladimir Oltean
Convert the Xilinx AXI ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/xilinx/xilinx_axienet_main.c | 38 +++++++++----------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 197740781157..c2f4c5ca2e80 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1440,6 +1440,22 @@ static void axienet_mac_an_restart(struct phylink_config *config)
static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
const struct phylink_link_state *state)
+{
+ /* nothing meaningful to do */
+}
+
+static void axienet_mac_link_down(struct phylink_config *config,
+ unsigned int mode,
+ phy_interface_t interface)
+{
+ /* nothing meaningful to do */
+}
+
+static void axienet_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *ndev = to_net_dev(config->dev);
struct axienet_local *lp = netdev_priv(ndev);
@@ -1448,7 +1464,7 @@ static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
emmc_reg = axienet_ior(lp, XAE_EMMC_OFFSET);
emmc_reg &= ~XAE_EMMC_LINKSPEED_MASK;
- switch (state->speed) {
+ switch (speed) {
case SPEED_1000:
emmc_reg |= XAE_EMMC_LINKSPD_1000;
break;
@@ -1467,33 +1483,17 @@ static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
axienet_iow(lp, XAE_EMMC_OFFSET, emmc_reg);
fcc_reg = axienet_ior(lp, XAE_FCC_OFFSET);
- if (state->pause & MLO_PAUSE_TX)
+ if (tx_pause)
fcc_reg |= XAE_FCC_FCTX_MASK;
else
fcc_reg &= ~XAE_FCC_FCTX_MASK;
- if (state->pause & MLO_PAUSE_RX)
+ if (rx_pause)
fcc_reg |= XAE_FCC_FCRX_MASK;
else
fcc_reg &= ~XAE_FCC_FCRX_MASK;
axienet_iow(lp, XAE_FCC_OFFSET, fcc_reg);
}
-static void axienet_mac_link_down(struct phylink_config *config,
- unsigned int mode,
- phy_interface_t interface)
-{
- /* nothing meaningful to do */
-}
-
-static void axienet_mac_link_up(struct phylink_config *config,
- struct phy_device *phy,
- unsigned int mode, phy_interface_t interface,
- int speed, int duplex,
- bool tx_pause, bool rx_pause)
-{
- /* nothing meaningful to do */
-}
-
static const struct phylink_mac_ops axienet_phylink_ops = {
.validate = axienet_validate,
.mac_pcs_get_state = axienet_mac_pcs_get_state,
--
2.20.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 4/8] net: axienet: use resolved link config in mac_link_up()
@ 2020-02-26 10:23 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Nicolas Ferre, Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Convert the Xilinx AXI ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/xilinx/xilinx_axienet_main.c | 38 +++++++++----------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 197740781157..c2f4c5ca2e80 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1440,6 +1440,22 @@ static void axienet_mac_an_restart(struct phylink_config *config)
static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
const struct phylink_link_state *state)
+{
+ /* nothing meaningful to do */
+}
+
+static void axienet_mac_link_down(struct phylink_config *config,
+ unsigned int mode,
+ phy_interface_t interface)
+{
+ /* nothing meaningful to do */
+}
+
+static void axienet_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *ndev = to_net_dev(config->dev);
struct axienet_local *lp = netdev_priv(ndev);
@@ -1448,7 +1464,7 @@ static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
emmc_reg = axienet_ior(lp, XAE_EMMC_OFFSET);
emmc_reg &= ~XAE_EMMC_LINKSPEED_MASK;
- switch (state->speed) {
+ switch (speed) {
case SPEED_1000:
emmc_reg |= XAE_EMMC_LINKSPD_1000;
break;
@@ -1467,33 +1483,17 @@ static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
axienet_iow(lp, XAE_EMMC_OFFSET, emmc_reg);
fcc_reg = axienet_ior(lp, XAE_FCC_OFFSET);
- if (state->pause & MLO_PAUSE_TX)
+ if (tx_pause)
fcc_reg |= XAE_FCC_FCTX_MASK;
else
fcc_reg &= ~XAE_FCC_FCTX_MASK;
- if (state->pause & MLO_PAUSE_RX)
+ if (rx_pause)
fcc_reg |= XAE_FCC_FCRX_MASK;
else
fcc_reg &= ~XAE_FCC_FCRX_MASK;
axienet_iow(lp, XAE_FCC_OFFSET, fcc_reg);
}
-static void axienet_mac_link_down(struct phylink_config *config,
- unsigned int mode,
- phy_interface_t interface)
-{
- /* nothing meaningful to do */
-}
-
-static void axienet_mac_link_up(struct phylink_config *config,
- struct phy_device *phy,
- unsigned int mode, phy_interface_t interface,
- int speed, int duplex,
- bool tx_pause, bool rx_pause)
-{
- /* nothing meaningful to do */
-}
-
static const struct phylink_mac_ops axienet_phylink_ops = {
.validate = axienet_validate,
.mac_pcs_get_state = axienet_mac_pcs_get_state,
--
2.20.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 4/8] net: axienet: use resolved link config in mac_link_up()
@ 2020-02-26 10:23 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Convert the Xilinx AXI ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/xilinx/xilinx_axienet_main.c | 38 +++++++++----------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 197740781157..c2f4c5ca2e80 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1440,6 +1440,22 @@ static void axienet_mac_an_restart(struct phylink_config *config)
static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
const struct phylink_link_state *state)
+{
+ /* nothing meaningful to do */
+}
+
+static void axienet_mac_link_down(struct phylink_config *config,
+ unsigned int mode,
+ phy_interface_t interface)
+{
+ /* nothing meaningful to do */
+}
+
+static void axienet_mac_link_up(struct phylink_config *config,
+ struct phy_device *phy,
+ unsigned int mode, phy_interface_t interface,
+ int speed, int duplex,
+ bool tx_pause, bool rx_pause)
{
struct net_device *ndev = to_net_dev(config->dev);
struct axienet_local *lp = netdev_priv(ndev);
@@ -1448,7 +1464,7 @@ static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
emmc_reg = axienet_ior(lp, XAE_EMMC_OFFSET);
emmc_reg &= ~XAE_EMMC_LINKSPEED_MASK;
- switch (state->speed) {
+ switch (speed) {
case SPEED_1000:
emmc_reg |= XAE_EMMC_LINKSPD_1000;
break;
@@ -1467,33 +1483,17 @@ static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
axienet_iow(lp, XAE_EMMC_OFFSET, emmc_reg);
fcc_reg = axienet_ior(lp, XAE_FCC_OFFSET);
- if (state->pause & MLO_PAUSE_TX)
+ if (tx_pause)
fcc_reg |= XAE_FCC_FCTX_MASK;
else
fcc_reg &= ~XAE_FCC_FCTX_MASK;
- if (state->pause & MLO_PAUSE_RX)
+ if (rx_pause)
fcc_reg |= XAE_FCC_FCRX_MASK;
else
fcc_reg &= ~XAE_FCC_FCRX_MASK;
axienet_iow(lp, XAE_FCC_OFFSET, fcc_reg);
}
-static void axienet_mac_link_down(struct phylink_config *config,
- unsigned int mode,
- phy_interface_t interface)
-{
- /* nothing meaningful to do */
-}
-
-static void axienet_mac_link_up(struct phylink_config *config,
- struct phy_device *phy,
- unsigned int mode, phy_interface_t interface,
- int speed, int duplex,
- bool tx_pause, bool rx_pause)
-{
- /* nothing meaningful to do */
-}
-
static const struct phylink_mac_ops axienet_phylink_ops = {
.validate = axienet_validate,
.mac_pcs_get_state = axienet_mac_pcs_get_state,
--
2.20.1
_______________________________________________
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] 60+ messages in thread
* [PATCH net-next v2 5/8] net: dpaa2-mac: use resolved link config in mac_link_up()
2020-02-26 10:23 ` Russell King - ARM Linux admin
(?)
@ 2020-02-26 10:24 ` Russell King
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: Alexandre Torgue, David S. Miller, Felix Fietkau,
Giuseppe Cavallaro, Hauke Mehrtens, Ioana Ciornei,
Jakub Kicinski, John Crispin, Jonathan Corbet, Jose Abreu,
linux-arm-kernel, linux-doc, linux-mediatek, linux-stm32,
Mark Lee, Matthias Brugger, Maxime Coquelin, Michal Simek,
netdev, Nicolas Ferre, Radhey Shyam Pandey, Sean Wang,
Thomas Petazzoni, Vivien Didelot, Vladimir Oltean,
Ioana Radulescu
Convert the DPAA2 ethernet driver to use the finalised link parameters
in mac_link_up() rather than the parameters in mac_config(), which are
more suited to the needs of the DPAA2 MC firmware than those available
via mac_config().
Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 54 +++++++++++--------
.../net/ethernet/freescale/dpaa2/dpaa2-mac.h | 1 +
2 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
index 3a75c5b58f95..3ee236c5fc37 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
@@ -123,35 +123,16 @@ static void dpaa2_mac_config(struct phylink_config *config, unsigned int mode,
struct dpmac_link_state *dpmac_state = &mac->state;
int err;
- if (state->speed != SPEED_UNKNOWN)
- dpmac_state->rate = state->speed;
-
- if (state->duplex != DUPLEX_UNKNOWN) {
- if (!state->duplex)
- dpmac_state->options |= DPMAC_LINK_OPT_HALF_DUPLEX;
- else
- dpmac_state->options &= ~DPMAC_LINK_OPT_HALF_DUPLEX;
- }
-
if (state->an_enabled)
dpmac_state->options |= DPMAC_LINK_OPT_AUTONEG;
else
dpmac_state->options &= ~DPMAC_LINK_OPT_AUTONEG;
- if (state->pause & MLO_PAUSE_RX)
- dpmac_state->options |= DPMAC_LINK_OPT_PAUSE;
- else
- dpmac_state->options &= ~DPMAC_LINK_OPT_PAUSE;
-
- if (!!(state->pause & MLO_PAUSE_RX) ^ !!(state->pause & MLO_PAUSE_TX))
- dpmac_state->options |= DPMAC_LINK_OPT_ASYM_PAUSE;
- else
- dpmac_state->options &= ~DPMAC_LINK_OPT_ASYM_PAUSE;
-
err = dpmac_set_link_state(mac->mc_io, 0,
mac->mc_dev->mc_handle, dpmac_state);
if (err)
- netdev_err(mac->net_dev, "dpmac_set_link_state() = %d\n", err);
+ netdev_err(mac->net_dev, "%s: dpmac_set_link_state() = %d\n",
+ __func__, err);
}
static void dpaa2_mac_link_up(struct phylink_config *config,
@@ -165,10 +146,37 @@ static void dpaa2_mac_link_up(struct phylink_config *config,
int err;
dpmac_state->up = 1;
+
+ if (mac->if_link_type == DPMAC_LINK_TYPE_PHY) {
+ /* If the DPMAC is configured for PHY mode, we need
+ * to pass the link parameters to the MC firmware.
+ */
+ dpmac_state->rate = speed;
+
+ if (duplex == DUPLEX_HALF)
+ dpmac_state->options |= DPMAC_LINK_OPT_HALF_DUPLEX;
+ else if (duplex == DUPLEX_FULL)
+ dpmac_state->options &= ~DPMAC_LINK_OPT_HALF_DUPLEX;
+
+ /* This is lossy; the firmware really should take the pause
+ * enablement status rather than pause/asym pause status.
+ */
+ if (rx_pause)
+ dpmac_state->options |= DPMAC_LINK_OPT_PAUSE;
+ else
+ dpmac_state->options &= ~DPMAC_LINK_OPT_PAUSE;
+
+ if (rx_pause ^ tx_pause)
+ dpmac_state->options |= DPMAC_LINK_OPT_ASYM_PAUSE;
+ else
+ dpmac_state->options &= ~DPMAC_LINK_OPT_ASYM_PAUSE;
+ }
+
err = dpmac_set_link_state(mac->mc_io, 0,
mac->mc_dev->mc_handle, dpmac_state);
if (err)
- netdev_err(mac->net_dev, "dpmac_set_link_state() = %d\n", err);
+ netdev_err(mac->net_dev, "%s: dpmac_set_link_state() = %d\n",
+ __func__, err);
}
static void dpaa2_mac_link_down(struct phylink_config *config,
@@ -241,6 +249,8 @@ int dpaa2_mac_connect(struct dpaa2_mac *mac)
goto err_close_dpmac;
}
+ mac->if_link_type = attr.link_type;
+
dpmac_node = dpaa2_mac_get_node(attr.id);
if (!dpmac_node) {
netdev_err(net_dev, "No dpmac@%d node found.\n", attr.id);
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h
index 4da8079b9155..2130d9c7d40e 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h
@@ -20,6 +20,7 @@ struct dpaa2_mac {
struct phylink_config phylink_config;
struct phylink *phylink;
phy_interface_t if_mode;
+ enum dpmac_link_type if_link_type;
};
bool dpaa2_mac_is_type_fixed(struct fsl_mc_device *dpmac_dev,
--
2.20.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 5/8] net: dpaa2-mac: use resolved link config in mac_link_up()
@ 2020-02-26 10:24 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Ioana Radulescu, Jonathan Corbet, Michal Simek, Jose Abreu,
Jakub Kicinski, Mark Lee, Sean Wang, Alexandre Torgue,
Hauke Mehrtens, Radhey Shyam Pandey, linux-mediatek,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
linux-arm-kernel, netdev, Nicolas Ferre, Vivien Didelot,
Maxime Coquelin, Vladimir Oltean, David S. Miller, Felix Fietkau
Convert the DPAA2 ethernet driver to use the finalised link parameters
in mac_link_up() rather than the parameters in mac_config(), which are
more suited to the needs of the DPAA2 MC firmware than those available
via mac_config().
Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 54 +++++++++++--------
.../net/ethernet/freescale/dpaa2/dpaa2-mac.h | 1 +
2 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
index 3a75c5b58f95..3ee236c5fc37 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
@@ -123,35 +123,16 @@ static void dpaa2_mac_config(struct phylink_config *config, unsigned int mode,
struct dpmac_link_state *dpmac_state = &mac->state;
int err;
- if (state->speed != SPEED_UNKNOWN)
- dpmac_state->rate = state->speed;
-
- if (state->duplex != DUPLEX_UNKNOWN) {
- if (!state->duplex)
- dpmac_state->options |= DPMAC_LINK_OPT_HALF_DUPLEX;
- else
- dpmac_state->options &= ~DPMAC_LINK_OPT_HALF_DUPLEX;
- }
-
if (state->an_enabled)
dpmac_state->options |= DPMAC_LINK_OPT_AUTONEG;
else
dpmac_state->options &= ~DPMAC_LINK_OPT_AUTONEG;
- if (state->pause & MLO_PAUSE_RX)
- dpmac_state->options |= DPMAC_LINK_OPT_PAUSE;
- else
- dpmac_state->options &= ~DPMAC_LINK_OPT_PAUSE;
-
- if (!!(state->pause & MLO_PAUSE_RX) ^ !!(state->pause & MLO_PAUSE_TX))
- dpmac_state->options |= DPMAC_LINK_OPT_ASYM_PAUSE;
- else
- dpmac_state->options &= ~DPMAC_LINK_OPT_ASYM_PAUSE;
-
err = dpmac_set_link_state(mac->mc_io, 0,
mac->mc_dev->mc_handle, dpmac_state);
if (err)
- netdev_err(mac->net_dev, "dpmac_set_link_state() = %d\n", err);
+ netdev_err(mac->net_dev, "%s: dpmac_set_link_state() = %d\n",
+ __func__, err);
}
static void dpaa2_mac_link_up(struct phylink_config *config,
@@ -165,10 +146,37 @@ static void dpaa2_mac_link_up(struct phylink_config *config,
int err;
dpmac_state->up = 1;
+
+ if (mac->if_link_type == DPMAC_LINK_TYPE_PHY) {
+ /* If the DPMAC is configured for PHY mode, we need
+ * to pass the link parameters to the MC firmware.
+ */
+ dpmac_state->rate = speed;
+
+ if (duplex == DUPLEX_HALF)
+ dpmac_state->options |= DPMAC_LINK_OPT_HALF_DUPLEX;
+ else if (duplex == DUPLEX_FULL)
+ dpmac_state->options &= ~DPMAC_LINK_OPT_HALF_DUPLEX;
+
+ /* This is lossy; the firmware really should take the pause
+ * enablement status rather than pause/asym pause status.
+ */
+ if (rx_pause)
+ dpmac_state->options |= DPMAC_LINK_OPT_PAUSE;
+ else
+ dpmac_state->options &= ~DPMAC_LINK_OPT_PAUSE;
+
+ if (rx_pause ^ tx_pause)
+ dpmac_state->options |= DPMAC_LINK_OPT_ASYM_PAUSE;
+ else
+ dpmac_state->options &= ~DPMAC_LINK_OPT_ASYM_PAUSE;
+ }
+
err = dpmac_set_link_state(mac->mc_io, 0,
mac->mc_dev->mc_handle, dpmac_state);
if (err)
- netdev_err(mac->net_dev, "dpmac_set_link_state() = %d\n", err);
+ netdev_err(mac->net_dev, "%s: dpmac_set_link_state() = %d\n",
+ __func__, err);
}
static void dpaa2_mac_link_down(struct phylink_config *config,
@@ -241,6 +249,8 @@ int dpaa2_mac_connect(struct dpaa2_mac *mac)
goto err_close_dpmac;
}
+ mac->if_link_type = attr.link_type;
+
dpmac_node = dpaa2_mac_get_node(attr.id);
if (!dpmac_node) {
netdev_err(net_dev, "No dpmac@%d node found.\n", attr.id);
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h
index 4da8079b9155..2130d9c7d40e 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h
@@ -20,6 +20,7 @@ struct dpaa2_mac {
struct phylink_config phylink_config;
struct phylink *phylink;
phy_interface_t if_mode;
+ enum dpmac_link_type if_link_type;
};
bool dpaa2_mac_is_type_fixed(struct fsl_mc_device *dpmac_dev,
--
2.20.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 5/8] net: dpaa2-mac: use resolved link config in mac_link_up()
@ 2020-02-26 10:24 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Ioana Radulescu, Jonathan Corbet, Michal Simek, Jose Abreu,
Jakub Kicinski, Mark Lee, Sean Wang, Alexandre Torgue,
Hauke Mehrtens, Radhey Shyam Pandey, linux-mediatek,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
linux-arm-kernel, netdev, Vivien Didelot, Maxime Coquelin,
Vladimir Oltean, David S. Miller, Felix Fietkau
Convert the DPAA2 ethernet driver to use the finalised link parameters
in mac_link_up() rather than the parameters in mac_config(), which are
more suited to the needs of the DPAA2 MC firmware than those available
via mac_config().
Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 54 +++++++++++--------
.../net/ethernet/freescale/dpaa2/dpaa2-mac.h | 1 +
2 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
index 3a75c5b58f95..3ee236c5fc37 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
@@ -123,35 +123,16 @@ static void dpaa2_mac_config(struct phylink_config *config, unsigned int mode,
struct dpmac_link_state *dpmac_state = &mac->state;
int err;
- if (state->speed != SPEED_UNKNOWN)
- dpmac_state->rate = state->speed;
-
- if (state->duplex != DUPLEX_UNKNOWN) {
- if (!state->duplex)
- dpmac_state->options |= DPMAC_LINK_OPT_HALF_DUPLEX;
- else
- dpmac_state->options &= ~DPMAC_LINK_OPT_HALF_DUPLEX;
- }
-
if (state->an_enabled)
dpmac_state->options |= DPMAC_LINK_OPT_AUTONEG;
else
dpmac_state->options &= ~DPMAC_LINK_OPT_AUTONEG;
- if (state->pause & MLO_PAUSE_RX)
- dpmac_state->options |= DPMAC_LINK_OPT_PAUSE;
- else
- dpmac_state->options &= ~DPMAC_LINK_OPT_PAUSE;
-
- if (!!(state->pause & MLO_PAUSE_RX) ^ !!(state->pause & MLO_PAUSE_TX))
- dpmac_state->options |= DPMAC_LINK_OPT_ASYM_PAUSE;
- else
- dpmac_state->options &= ~DPMAC_LINK_OPT_ASYM_PAUSE;
-
err = dpmac_set_link_state(mac->mc_io, 0,
mac->mc_dev->mc_handle, dpmac_state);
if (err)
- netdev_err(mac->net_dev, "dpmac_set_link_state() = %d\n", err);
+ netdev_err(mac->net_dev, "%s: dpmac_set_link_state() = %d\n",
+ __func__, err);
}
static void dpaa2_mac_link_up(struct phylink_config *config,
@@ -165,10 +146,37 @@ static void dpaa2_mac_link_up(struct phylink_config *config,
int err;
dpmac_state->up = 1;
+
+ if (mac->if_link_type == DPMAC_LINK_TYPE_PHY) {
+ /* If the DPMAC is configured for PHY mode, we need
+ * to pass the link parameters to the MC firmware.
+ */
+ dpmac_state->rate = speed;
+
+ if (duplex == DUPLEX_HALF)
+ dpmac_state->options |= DPMAC_LINK_OPT_HALF_DUPLEX;
+ else if (duplex == DUPLEX_FULL)
+ dpmac_state->options &= ~DPMAC_LINK_OPT_HALF_DUPLEX;
+
+ /* This is lossy; the firmware really should take the pause
+ * enablement status rather than pause/asym pause status.
+ */
+ if (rx_pause)
+ dpmac_state->options |= DPMAC_LINK_OPT_PAUSE;
+ else
+ dpmac_state->options &= ~DPMAC_LINK_OPT_PAUSE;
+
+ if (rx_pause ^ tx_pause)
+ dpmac_state->options |= DPMAC_LINK_OPT_ASYM_PAUSE;
+ else
+ dpmac_state->options &= ~DPMAC_LINK_OPT_ASYM_PAUSE;
+ }
+
err = dpmac_set_link_state(mac->mc_io, 0,
mac->mc_dev->mc_handle, dpmac_state);
if (err)
- netdev_err(mac->net_dev, "dpmac_set_link_state() = %d\n", err);
+ netdev_err(mac->net_dev, "%s: dpmac_set_link_state() = %d\n",
+ __func__, err);
}
static void dpaa2_mac_link_down(struct phylink_config *config,
@@ -241,6 +249,8 @@ int dpaa2_mac_connect(struct dpaa2_mac *mac)
goto err_close_dpmac;
}
+ mac->if_link_type = attr.link_type;
+
dpmac_node = dpaa2_mac_get_node(attr.id);
if (!dpmac_node) {
netdev_err(net_dev, "No dpmac@%d node found.\n", attr.id);
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h
index 4da8079b9155..2130d9c7d40e 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.h
@@ -20,6 +20,7 @@ struct dpaa2_mac {
struct phylink_config phylink_config;
struct phylink *phylink;
phy_interface_t if_mode;
+ enum dpmac_link_type if_link_type;
};
bool dpaa2_mac_is_type_fixed(struct fsl_mc_device *dpmac_dev,
--
2.20.1
_______________________________________________
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] 60+ messages in thread
* [PATCH net-next v2 6/8] net: macb: use resolved link config in mac_link_up()
2020-02-26 10:23 ` Russell King - ARM Linux admin
(?)
@ 2020-02-26 10:24 ` Russell King
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: Alexandre Torgue, David S. Miller, Felix Fietkau,
Giuseppe Cavallaro, Hauke Mehrtens, Ioana Ciornei,
Jakub Kicinski, John Crispin, Jonathan Corbet, Jose Abreu,
linux-arm-kernel, linux-doc, linux-mediatek, linux-stm32,
Mark Lee, Matthias Brugger, Maxime Coquelin, Michal Simek,
netdev, Nicolas Ferre, Radhey Shyam Pandey, Sean Wang,
Thomas Petazzoni, Vivien Didelot, Vladimir Oltean
Convert the macb ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/cadence/macb.h | 1 -
drivers/net/ethernet/cadence/macb_main.c | 50 ++++++++++++++----------
2 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index a3f0f27fc79a..ab827fb4b6b9 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -1200,7 +1200,6 @@ struct macb {
unsigned int dma_burst_length;
phy_interface_t phy_interface;
- int speed;
/* AT91RM9200 transmit */
struct sk_buff *skb; /* holds skb until xmit interrupt completes */
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 7ab0bef5e1bd..3a7c26b08607 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -571,37 +571,20 @@ static void macb_mac_config(struct phylink_config *config, unsigned int mode,
old_ctrl = ctrl = macb_or_gem_readl(bp, NCFGR);
- /* Clear all the bits we might set later */
- ctrl &= ~(MACB_BIT(SPD) | MACB_BIT(FD) | MACB_BIT(PAE));
-
if (bp->caps & MACB_CAPS_MACB_IS_EMAC) {
if (state->interface == PHY_INTERFACE_MODE_RMII)
ctrl |= MACB_BIT(RM9200_RMII);
} else {
- ctrl &= ~(GEM_BIT(GBE) | GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL));
-
- /* We do not support MLO_PAUSE_RX yet */
- if (state->pause & MLO_PAUSE_TX)
- ctrl |= MACB_BIT(PAE);
+ ctrl &= ~(GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL));
if (state->interface == PHY_INTERFACE_MODE_SGMII)
ctrl |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL);
}
- if (state->speed == SPEED_1000)
- ctrl |= GEM_BIT(GBE);
- else if (state->speed == SPEED_100)
- ctrl |= MACB_BIT(SPD);
-
- if (state->duplex)
- ctrl |= MACB_BIT(FD);
-
/* Apply the new configuration, if any */
if (old_ctrl ^ ctrl)
macb_or_gem_writel(bp, NCFGR, ctrl);
- bp->speed = state->speed;
-
spin_unlock_irqrestore(&bp->lock, flags);
}
@@ -635,10 +618,33 @@ static void macb_mac_link_up(struct phylink_config *config,
struct net_device *ndev = to_net_dev(config->dev);
struct macb *bp = netdev_priv(ndev);
struct macb_queue *queue;
+ unsigned long flags;
unsigned int q;
+ u32 ctrl;
+
+ spin_lock_irqsave(&bp->lock, flags);
+
+ ctrl = macb_or_gem_readl(bp, NCFGR);
+
+ ctrl &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
+
+ if (speed == SPEED_100)
+ ctrl |= MACB_BIT(SPD);
+
+ if (duplex)
+ ctrl |= MACB_BIT(FD);
if (!(bp->caps & MACB_CAPS_MACB_IS_EMAC)) {
- macb_set_tx_clk(bp->tx_clk, bp->speed, ndev);
+ ctrl &= ~(GEM_BIT(GBE) | MACB_BIT(PAE));
+
+ if (speed == SPEED_1000)
+ ctrl |= GEM_BIT(GBE);
+
+ /* We do not support MLO_PAUSE_RX yet */
+ if (tx_pause)
+ ctrl |= MACB_BIT(PAE);
+
+ macb_set_tx_clk(bp->tx_clk, speed, ndev);
/* Initialize rings & buffers as clearing MACB_BIT(TE) in link down
* cleared the pipeline and control registers.
@@ -651,6 +657,10 @@ static void macb_mac_link_up(struct phylink_config *config,
bp->rx_intr_mask | MACB_TX_INT_FLAGS | MACB_BIT(HRESP));
}
+ macb_or_gem_writel(bp, NCFGR, ctrl);
+
+ spin_unlock_irqrestore(&bp->lock, flags);
+
/* Enable Rx and Tx */
macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(RE) | MACB_BIT(TE));
@@ -4432,8 +4442,6 @@ static int macb_probe(struct platform_device *pdev)
else
bp->phy_interface = interface;
- bp->speed = SPEED_UNKNOWN;
-
/* IP specific init */
err = init(pdev);
if (err)
--
2.20.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 6/8] net: macb: use resolved link config in mac_link_up()
@ 2020-02-26 10:24 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Nicolas Ferre, Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Convert the macb ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/cadence/macb.h | 1 -
drivers/net/ethernet/cadence/macb_main.c | 50 ++++++++++++++----------
2 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index a3f0f27fc79a..ab827fb4b6b9 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -1200,7 +1200,6 @@ struct macb {
unsigned int dma_burst_length;
phy_interface_t phy_interface;
- int speed;
/* AT91RM9200 transmit */
struct sk_buff *skb; /* holds skb until xmit interrupt completes */
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 7ab0bef5e1bd..3a7c26b08607 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -571,37 +571,20 @@ static void macb_mac_config(struct phylink_config *config, unsigned int mode,
old_ctrl = ctrl = macb_or_gem_readl(bp, NCFGR);
- /* Clear all the bits we might set later */
- ctrl &= ~(MACB_BIT(SPD) | MACB_BIT(FD) | MACB_BIT(PAE));
-
if (bp->caps & MACB_CAPS_MACB_IS_EMAC) {
if (state->interface == PHY_INTERFACE_MODE_RMII)
ctrl |= MACB_BIT(RM9200_RMII);
} else {
- ctrl &= ~(GEM_BIT(GBE) | GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL));
-
- /* We do not support MLO_PAUSE_RX yet */
- if (state->pause & MLO_PAUSE_TX)
- ctrl |= MACB_BIT(PAE);
+ ctrl &= ~(GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL));
if (state->interface == PHY_INTERFACE_MODE_SGMII)
ctrl |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL);
}
- if (state->speed == SPEED_1000)
- ctrl |= GEM_BIT(GBE);
- else if (state->speed == SPEED_100)
- ctrl |= MACB_BIT(SPD);
-
- if (state->duplex)
- ctrl |= MACB_BIT(FD);
-
/* Apply the new configuration, if any */
if (old_ctrl ^ ctrl)
macb_or_gem_writel(bp, NCFGR, ctrl);
- bp->speed = state->speed;
-
spin_unlock_irqrestore(&bp->lock, flags);
}
@@ -635,10 +618,33 @@ static void macb_mac_link_up(struct phylink_config *config,
struct net_device *ndev = to_net_dev(config->dev);
struct macb *bp = netdev_priv(ndev);
struct macb_queue *queue;
+ unsigned long flags;
unsigned int q;
+ u32 ctrl;
+
+ spin_lock_irqsave(&bp->lock, flags);
+
+ ctrl = macb_or_gem_readl(bp, NCFGR);
+
+ ctrl &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
+
+ if (speed == SPEED_100)
+ ctrl |= MACB_BIT(SPD);
+
+ if (duplex)
+ ctrl |= MACB_BIT(FD);
if (!(bp->caps & MACB_CAPS_MACB_IS_EMAC)) {
- macb_set_tx_clk(bp->tx_clk, bp->speed, ndev);
+ ctrl &= ~(GEM_BIT(GBE) | MACB_BIT(PAE));
+
+ if (speed == SPEED_1000)
+ ctrl |= GEM_BIT(GBE);
+
+ /* We do not support MLO_PAUSE_RX yet */
+ if (tx_pause)
+ ctrl |= MACB_BIT(PAE);
+
+ macb_set_tx_clk(bp->tx_clk, speed, ndev);
/* Initialize rings & buffers as clearing MACB_BIT(TE) in link down
* cleared the pipeline and control registers.
@@ -651,6 +657,10 @@ static void macb_mac_link_up(struct phylink_config *config,
bp->rx_intr_mask | MACB_TX_INT_FLAGS | MACB_BIT(HRESP));
}
+ macb_or_gem_writel(bp, NCFGR, ctrl);
+
+ spin_unlock_irqrestore(&bp->lock, flags);
+
/* Enable Rx and Tx */
macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(RE) | MACB_BIT(TE));
@@ -4432,8 +4442,6 @@ static int macb_probe(struct platform_device *pdev)
else
bp->phy_interface = interface;
- bp->speed = SPEED_UNKNOWN;
-
/* IP specific init */
err = init(pdev);
if (err)
--
2.20.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 6/8] net: macb: use resolved link config in mac_link_up()
@ 2020-02-26 10:24 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Convert the macb ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/cadence/macb.h | 1 -
drivers/net/ethernet/cadence/macb_main.c | 50 ++++++++++++++----------
2 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index a3f0f27fc79a..ab827fb4b6b9 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -1200,7 +1200,6 @@ struct macb {
unsigned int dma_burst_length;
phy_interface_t phy_interface;
- int speed;
/* AT91RM9200 transmit */
struct sk_buff *skb; /* holds skb until xmit interrupt completes */
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 7ab0bef5e1bd..3a7c26b08607 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -571,37 +571,20 @@ static void macb_mac_config(struct phylink_config *config, unsigned int mode,
old_ctrl = ctrl = macb_or_gem_readl(bp, NCFGR);
- /* Clear all the bits we might set later */
- ctrl &= ~(MACB_BIT(SPD) | MACB_BIT(FD) | MACB_BIT(PAE));
-
if (bp->caps & MACB_CAPS_MACB_IS_EMAC) {
if (state->interface == PHY_INTERFACE_MODE_RMII)
ctrl |= MACB_BIT(RM9200_RMII);
} else {
- ctrl &= ~(GEM_BIT(GBE) | GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL));
-
- /* We do not support MLO_PAUSE_RX yet */
- if (state->pause & MLO_PAUSE_TX)
- ctrl |= MACB_BIT(PAE);
+ ctrl &= ~(GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL));
if (state->interface == PHY_INTERFACE_MODE_SGMII)
ctrl |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL);
}
- if (state->speed == SPEED_1000)
- ctrl |= GEM_BIT(GBE);
- else if (state->speed == SPEED_100)
- ctrl |= MACB_BIT(SPD);
-
- if (state->duplex)
- ctrl |= MACB_BIT(FD);
-
/* Apply the new configuration, if any */
if (old_ctrl ^ ctrl)
macb_or_gem_writel(bp, NCFGR, ctrl);
- bp->speed = state->speed;
-
spin_unlock_irqrestore(&bp->lock, flags);
}
@@ -635,10 +618,33 @@ static void macb_mac_link_up(struct phylink_config *config,
struct net_device *ndev = to_net_dev(config->dev);
struct macb *bp = netdev_priv(ndev);
struct macb_queue *queue;
+ unsigned long flags;
unsigned int q;
+ u32 ctrl;
+
+ spin_lock_irqsave(&bp->lock, flags);
+
+ ctrl = macb_or_gem_readl(bp, NCFGR);
+
+ ctrl &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
+
+ if (speed == SPEED_100)
+ ctrl |= MACB_BIT(SPD);
+
+ if (duplex)
+ ctrl |= MACB_BIT(FD);
if (!(bp->caps & MACB_CAPS_MACB_IS_EMAC)) {
- macb_set_tx_clk(bp->tx_clk, bp->speed, ndev);
+ ctrl &= ~(GEM_BIT(GBE) | MACB_BIT(PAE));
+
+ if (speed == SPEED_1000)
+ ctrl |= GEM_BIT(GBE);
+
+ /* We do not support MLO_PAUSE_RX yet */
+ if (tx_pause)
+ ctrl |= MACB_BIT(PAE);
+
+ macb_set_tx_clk(bp->tx_clk, speed, ndev);
/* Initialize rings & buffers as clearing MACB_BIT(TE) in link down
* cleared the pipeline and control registers.
@@ -651,6 +657,10 @@ static void macb_mac_link_up(struct phylink_config *config,
bp->rx_intr_mask | MACB_TX_INT_FLAGS | MACB_BIT(HRESP));
}
+ macb_or_gem_writel(bp, NCFGR, ctrl);
+
+ spin_unlock_irqrestore(&bp->lock, flags);
+
/* Enable Rx and Tx */
macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(RE) | MACB_BIT(TE));
@@ -4432,8 +4442,6 @@ static int macb_probe(struct platform_device *pdev)
else
bp->phy_interface = interface;
- bp->speed = SPEED_UNKNOWN;
-
/* IP specific init */
err = init(pdev);
if (err)
--
2.20.1
_______________________________________________
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] 60+ messages in thread
* [PATCH net-next v2 7/8] net: mvneta: use resolved link config in mac_link_up()
2020-02-26 10:23 ` Russell King - ARM Linux admin
(?)
@ 2020-02-26 10:24 ` Russell King
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: Alexandre Torgue, David S. Miller, Felix Fietkau,
Giuseppe Cavallaro, Hauke Mehrtens, Ioana Ciornei,
Jakub Kicinski, John Crispin, Jonathan Corbet, Jose Abreu,
linux-arm-kernel, linux-doc, linux-mediatek, linux-stm32,
Mark Lee, Matthias Brugger, Maxime Coquelin, Michal Simek,
netdev, Nicolas Ferre, Radhey Shyam Pandey, Sean Wang,
Thomas Petazzoni, Vivien Didelot, Vladimir Oltean
Convert the Marvell mvneta ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvneta.c | 55 ++++++++++++++++++---------
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 9af3f8d5b289..b22eeb5f8700 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3830,13 +3830,9 @@ static void mvneta_mac_config(struct phylink_config *config, unsigned int mode,
new_clk = gmac_clk & ~MVNETA_GMAC_1MS_CLOCK_ENABLE;
new_an = gmac_an & ~(MVNETA_GMAC_INBAND_AN_ENABLE |
MVNETA_GMAC_INBAND_RESTART_AN |
- MVNETA_GMAC_CONFIG_MII_SPEED |
- MVNETA_GMAC_CONFIG_GMII_SPEED |
MVNETA_GMAC_AN_SPEED_EN |
MVNETA_GMAC_ADVERT_SYM_FLOW_CTRL |
- MVNETA_GMAC_CONFIG_FLOW_CTRL |
MVNETA_GMAC_AN_FLOW_CTRL_EN |
- MVNETA_GMAC_CONFIG_FULL_DUPLEX |
MVNETA_GMAC_AN_DUPLEX_EN);
/* Even though it might look weird, when we're configured in
@@ -3851,24 +3847,20 @@ static void mvneta_mac_config(struct phylink_config *config, unsigned int mode,
if (phylink_test(state->advertising, Pause))
new_an |= MVNETA_GMAC_ADVERT_SYM_FLOW_CTRL;
- if (state->pause & MLO_PAUSE_TXRX_MASK)
- new_an |= MVNETA_GMAC_CONFIG_FLOW_CTRL;
if (!phylink_autoneg_inband(mode)) {
- /* Phy or fixed speed */
- if (state->duplex)
- new_an |= MVNETA_GMAC_CONFIG_FULL_DUPLEX;
-
- if (state->speed == SPEED_1000 || state->speed == SPEED_2500)
- new_an |= MVNETA_GMAC_CONFIG_GMII_SPEED;
- else if (state->speed == SPEED_100)
- new_an |= MVNETA_GMAC_CONFIG_MII_SPEED;
+ /* Phy or fixed speed - nothing to do, leave the
+ * configured speed, duplex and flow control as-is.
+ */
} else if (state->interface == PHY_INTERFACE_MODE_SGMII) {
/* SGMII mode receives the state from the PHY */
new_ctrl2 |= MVNETA_GMAC2_INBAND_AN_ENABLE;
new_clk |= MVNETA_GMAC_1MS_CLOCK_ENABLE;
new_an = (new_an & ~(MVNETA_GMAC_FORCE_LINK_DOWN |
- MVNETA_GMAC_FORCE_LINK_PASS)) |
+ MVNETA_GMAC_FORCE_LINK_PASS |
+ MVNETA_GMAC_CONFIG_MII_SPEED |
+ MVNETA_GMAC_CONFIG_GMII_SPEED |
+ MVNETA_GMAC_CONFIG_FULL_DUPLEX)) |
MVNETA_GMAC_INBAND_AN_ENABLE |
MVNETA_GMAC_AN_SPEED_EN |
MVNETA_GMAC_AN_DUPLEX_EN;
@@ -3877,7 +3869,8 @@ static void mvneta_mac_config(struct phylink_config *config, unsigned int mode,
new_ctrl0 |= MVNETA_GMAC0_PORT_1000BASE_X;
new_clk |= MVNETA_GMAC_1MS_CLOCK_ENABLE;
new_an = (new_an & ~(MVNETA_GMAC_FORCE_LINK_DOWN |
- MVNETA_GMAC_FORCE_LINK_PASS)) |
+ MVNETA_GMAC_FORCE_LINK_PASS |
+ MVNETA_GMAC_CONFIG_MII_SPEED)) |
MVNETA_GMAC_INBAND_AN_ENABLE |
MVNETA_GMAC_CONFIG_GMII_SPEED |
/* The MAC only supports FD mode */
@@ -3977,8 +3970,36 @@ static void mvneta_mac_link_up(struct phylink_config *config,
if (!phylink_autoneg_inband(mode)) {
val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG);
- val &= ~MVNETA_GMAC_FORCE_LINK_DOWN;
+ val &= ~(MVNETA_GMAC_FORCE_LINK_DOWN |
+ MVNETA_GMAC_CONFIG_MII_SPEED |
+ MVNETA_GMAC_CONFIG_GMII_SPEED |
+ MVNETA_GMAC_CONFIG_FLOW_CTRL |
+ MVNETA_GMAC_CONFIG_FULL_DUPLEX);
val |= MVNETA_GMAC_FORCE_LINK_PASS;
+
+ if (speed == SPEED_1000 || speed == SPEED_2500)
+ val |= MVNETA_GMAC_CONFIG_GMII_SPEED;
+ else if (speed == SPEED_100)
+ val |= MVNETA_GMAC_CONFIG_MII_SPEED;
+
+ if (duplex == DUPLEX_FULL)
+ val |= MVNETA_GMAC_CONFIG_FULL_DUPLEX;
+
+ if (tx_pause || rx_pause)
+ val |= MVNETA_GMAC_CONFIG_FLOW_CTRL;
+
+ mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val);
+ } else {
+ /* When inband doesn't cover flow control or flow control is
+ * disabled, we need to manually configure it. This bit will
+ * only have effect if MVNETA_GMAC_AN_FLOW_CTRL_EN is unset.
+ */
+ val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG);
+ val &= ~MVNETA_GMAC_CONFIG_FLOW_CTRL;
+
+ if (tx_pause || rx_pause)
+ val |= MVNETA_GMAC_CONFIG_FLOW_CTRL;
+
mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val);
}
--
2.20.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 7/8] net: mvneta: use resolved link config in mac_link_up()
@ 2020-02-26 10:24 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Nicolas Ferre, Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Convert the Marvell mvneta ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvneta.c | 55 ++++++++++++++++++---------
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 9af3f8d5b289..b22eeb5f8700 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3830,13 +3830,9 @@ static void mvneta_mac_config(struct phylink_config *config, unsigned int mode,
new_clk = gmac_clk & ~MVNETA_GMAC_1MS_CLOCK_ENABLE;
new_an = gmac_an & ~(MVNETA_GMAC_INBAND_AN_ENABLE |
MVNETA_GMAC_INBAND_RESTART_AN |
- MVNETA_GMAC_CONFIG_MII_SPEED |
- MVNETA_GMAC_CONFIG_GMII_SPEED |
MVNETA_GMAC_AN_SPEED_EN |
MVNETA_GMAC_ADVERT_SYM_FLOW_CTRL |
- MVNETA_GMAC_CONFIG_FLOW_CTRL |
MVNETA_GMAC_AN_FLOW_CTRL_EN |
- MVNETA_GMAC_CONFIG_FULL_DUPLEX |
MVNETA_GMAC_AN_DUPLEX_EN);
/* Even though it might look weird, when we're configured in
@@ -3851,24 +3847,20 @@ static void mvneta_mac_config(struct phylink_config *config, unsigned int mode,
if (phylink_test(state->advertising, Pause))
new_an |= MVNETA_GMAC_ADVERT_SYM_FLOW_CTRL;
- if (state->pause & MLO_PAUSE_TXRX_MASK)
- new_an |= MVNETA_GMAC_CONFIG_FLOW_CTRL;
if (!phylink_autoneg_inband(mode)) {
- /* Phy or fixed speed */
- if (state->duplex)
- new_an |= MVNETA_GMAC_CONFIG_FULL_DUPLEX;
-
- if (state->speed == SPEED_1000 || state->speed == SPEED_2500)
- new_an |= MVNETA_GMAC_CONFIG_GMII_SPEED;
- else if (state->speed == SPEED_100)
- new_an |= MVNETA_GMAC_CONFIG_MII_SPEED;
+ /* Phy or fixed speed - nothing to do, leave the
+ * configured speed, duplex and flow control as-is.
+ */
} else if (state->interface == PHY_INTERFACE_MODE_SGMII) {
/* SGMII mode receives the state from the PHY */
new_ctrl2 |= MVNETA_GMAC2_INBAND_AN_ENABLE;
new_clk |= MVNETA_GMAC_1MS_CLOCK_ENABLE;
new_an = (new_an & ~(MVNETA_GMAC_FORCE_LINK_DOWN |
- MVNETA_GMAC_FORCE_LINK_PASS)) |
+ MVNETA_GMAC_FORCE_LINK_PASS |
+ MVNETA_GMAC_CONFIG_MII_SPEED |
+ MVNETA_GMAC_CONFIG_GMII_SPEED |
+ MVNETA_GMAC_CONFIG_FULL_DUPLEX)) |
MVNETA_GMAC_INBAND_AN_ENABLE |
MVNETA_GMAC_AN_SPEED_EN |
MVNETA_GMAC_AN_DUPLEX_EN;
@@ -3877,7 +3869,8 @@ static void mvneta_mac_config(struct phylink_config *config, unsigned int mode,
new_ctrl0 |= MVNETA_GMAC0_PORT_1000BASE_X;
new_clk |= MVNETA_GMAC_1MS_CLOCK_ENABLE;
new_an = (new_an & ~(MVNETA_GMAC_FORCE_LINK_DOWN |
- MVNETA_GMAC_FORCE_LINK_PASS)) |
+ MVNETA_GMAC_FORCE_LINK_PASS |
+ MVNETA_GMAC_CONFIG_MII_SPEED)) |
MVNETA_GMAC_INBAND_AN_ENABLE |
MVNETA_GMAC_CONFIG_GMII_SPEED |
/* The MAC only supports FD mode */
@@ -3977,8 +3970,36 @@ static void mvneta_mac_link_up(struct phylink_config *config,
if (!phylink_autoneg_inband(mode)) {
val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG);
- val &= ~MVNETA_GMAC_FORCE_LINK_DOWN;
+ val &= ~(MVNETA_GMAC_FORCE_LINK_DOWN |
+ MVNETA_GMAC_CONFIG_MII_SPEED |
+ MVNETA_GMAC_CONFIG_GMII_SPEED |
+ MVNETA_GMAC_CONFIG_FLOW_CTRL |
+ MVNETA_GMAC_CONFIG_FULL_DUPLEX);
val |= MVNETA_GMAC_FORCE_LINK_PASS;
+
+ if (speed == SPEED_1000 || speed == SPEED_2500)
+ val |= MVNETA_GMAC_CONFIG_GMII_SPEED;
+ else if (speed == SPEED_100)
+ val |= MVNETA_GMAC_CONFIG_MII_SPEED;
+
+ if (duplex == DUPLEX_FULL)
+ val |= MVNETA_GMAC_CONFIG_FULL_DUPLEX;
+
+ if (tx_pause || rx_pause)
+ val |= MVNETA_GMAC_CONFIG_FLOW_CTRL;
+
+ mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val);
+ } else {
+ /* When inband doesn't cover flow control or flow control is
+ * disabled, we need to manually configure it. This bit will
+ * only have effect if MVNETA_GMAC_AN_FLOW_CTRL_EN is unset.
+ */
+ val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG);
+ val &= ~MVNETA_GMAC_CONFIG_FLOW_CTRL;
+
+ if (tx_pause || rx_pause)
+ val |= MVNETA_GMAC_CONFIG_FLOW_CTRL;
+
mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val);
}
--
2.20.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 7/8] net: mvneta: use resolved link config in mac_link_up()
@ 2020-02-26 10:24 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Convert the Marvell mvneta ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvneta.c | 55 ++++++++++++++++++---------
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 9af3f8d5b289..b22eeb5f8700 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3830,13 +3830,9 @@ static void mvneta_mac_config(struct phylink_config *config, unsigned int mode,
new_clk = gmac_clk & ~MVNETA_GMAC_1MS_CLOCK_ENABLE;
new_an = gmac_an & ~(MVNETA_GMAC_INBAND_AN_ENABLE |
MVNETA_GMAC_INBAND_RESTART_AN |
- MVNETA_GMAC_CONFIG_MII_SPEED |
- MVNETA_GMAC_CONFIG_GMII_SPEED |
MVNETA_GMAC_AN_SPEED_EN |
MVNETA_GMAC_ADVERT_SYM_FLOW_CTRL |
- MVNETA_GMAC_CONFIG_FLOW_CTRL |
MVNETA_GMAC_AN_FLOW_CTRL_EN |
- MVNETA_GMAC_CONFIG_FULL_DUPLEX |
MVNETA_GMAC_AN_DUPLEX_EN);
/* Even though it might look weird, when we're configured in
@@ -3851,24 +3847,20 @@ static void mvneta_mac_config(struct phylink_config *config, unsigned int mode,
if (phylink_test(state->advertising, Pause))
new_an |= MVNETA_GMAC_ADVERT_SYM_FLOW_CTRL;
- if (state->pause & MLO_PAUSE_TXRX_MASK)
- new_an |= MVNETA_GMAC_CONFIG_FLOW_CTRL;
if (!phylink_autoneg_inband(mode)) {
- /* Phy or fixed speed */
- if (state->duplex)
- new_an |= MVNETA_GMAC_CONFIG_FULL_DUPLEX;
-
- if (state->speed == SPEED_1000 || state->speed == SPEED_2500)
- new_an |= MVNETA_GMAC_CONFIG_GMII_SPEED;
- else if (state->speed == SPEED_100)
- new_an |= MVNETA_GMAC_CONFIG_MII_SPEED;
+ /* Phy or fixed speed - nothing to do, leave the
+ * configured speed, duplex and flow control as-is.
+ */
} else if (state->interface == PHY_INTERFACE_MODE_SGMII) {
/* SGMII mode receives the state from the PHY */
new_ctrl2 |= MVNETA_GMAC2_INBAND_AN_ENABLE;
new_clk |= MVNETA_GMAC_1MS_CLOCK_ENABLE;
new_an = (new_an & ~(MVNETA_GMAC_FORCE_LINK_DOWN |
- MVNETA_GMAC_FORCE_LINK_PASS)) |
+ MVNETA_GMAC_FORCE_LINK_PASS |
+ MVNETA_GMAC_CONFIG_MII_SPEED |
+ MVNETA_GMAC_CONFIG_GMII_SPEED |
+ MVNETA_GMAC_CONFIG_FULL_DUPLEX)) |
MVNETA_GMAC_INBAND_AN_ENABLE |
MVNETA_GMAC_AN_SPEED_EN |
MVNETA_GMAC_AN_DUPLEX_EN;
@@ -3877,7 +3869,8 @@ static void mvneta_mac_config(struct phylink_config *config, unsigned int mode,
new_ctrl0 |= MVNETA_GMAC0_PORT_1000BASE_X;
new_clk |= MVNETA_GMAC_1MS_CLOCK_ENABLE;
new_an = (new_an & ~(MVNETA_GMAC_FORCE_LINK_DOWN |
- MVNETA_GMAC_FORCE_LINK_PASS)) |
+ MVNETA_GMAC_FORCE_LINK_PASS |
+ MVNETA_GMAC_CONFIG_MII_SPEED)) |
MVNETA_GMAC_INBAND_AN_ENABLE |
MVNETA_GMAC_CONFIG_GMII_SPEED |
/* The MAC only supports FD mode */
@@ -3977,8 +3970,36 @@ static void mvneta_mac_link_up(struct phylink_config *config,
if (!phylink_autoneg_inband(mode)) {
val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG);
- val &= ~MVNETA_GMAC_FORCE_LINK_DOWN;
+ val &= ~(MVNETA_GMAC_FORCE_LINK_DOWN |
+ MVNETA_GMAC_CONFIG_MII_SPEED |
+ MVNETA_GMAC_CONFIG_GMII_SPEED |
+ MVNETA_GMAC_CONFIG_FLOW_CTRL |
+ MVNETA_GMAC_CONFIG_FULL_DUPLEX);
val |= MVNETA_GMAC_FORCE_LINK_PASS;
+
+ if (speed == SPEED_1000 || speed == SPEED_2500)
+ val |= MVNETA_GMAC_CONFIG_GMII_SPEED;
+ else if (speed == SPEED_100)
+ val |= MVNETA_GMAC_CONFIG_MII_SPEED;
+
+ if (duplex == DUPLEX_FULL)
+ val |= MVNETA_GMAC_CONFIG_FULL_DUPLEX;
+
+ if (tx_pause || rx_pause)
+ val |= MVNETA_GMAC_CONFIG_FLOW_CTRL;
+
+ mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val);
+ } else {
+ /* When inband doesn't cover flow control or flow control is
+ * disabled, we need to manually configure it. This bit will
+ * only have effect if MVNETA_GMAC_AN_FLOW_CTRL_EN is unset.
+ */
+ val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG);
+ val &= ~MVNETA_GMAC_CONFIG_FLOW_CTRL;
+
+ if (tx_pause || rx_pause)
+ val |= MVNETA_GMAC_CONFIG_FLOW_CTRL;
+
mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val);
}
--
2.20.1
_______________________________________________
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] 60+ messages in thread
* [PATCH net-next v2 8/8] net: mvpp2: use resolved link config in mac_link_up()
2020-02-26 10:23 ` Russell King - ARM Linux admin
(?)
@ 2020-02-26 10:24 ` Russell King
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: Alexandre Torgue, David S. Miller, Felix Fietkau,
Giuseppe Cavallaro, Hauke Mehrtens, Ioana Ciornei,
Jakub Kicinski, John Crispin, Jonathan Corbet, Jose Abreu,
linux-arm-kernel, linux-doc, linux-mediatek, linux-stm32,
Mark Lee, Matthias Brugger, Maxime Coquelin, Michal Simek,
netdev, Nicolas Ferre, Radhey Shyam Pandey, Sean Wang,
Thomas Petazzoni, Vivien Didelot, Vladimir Oltean
Convert the Marvell mvpp2 ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 83 +++++++++++--------
1 file changed, 47 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index ed8042d97e29..6b9c7ed2547e 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4976,15 +4976,13 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
old_ctrl2 = ctrl2 = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
old_ctrl4 = ctrl4 = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
- an &= ~(MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_CONFIG_GMII_SPEED |
- MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_FC_ADV_EN |
+ an &= ~(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_IN_BAND_AUTONEG | MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS);
+ MVPP2_GMAC_AN_DUPLEX_EN | MVPP2_GMAC_IN_BAND_AUTONEG |
+ MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS);
ctrl0 &= ~MVPP2_GMAC_PORT_TYPE_MASK;
ctrl2 &= ~(MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PORT_RESET_MASK |
MVPP2_GMAC_PCS_ENABLE_MASK);
- ctrl4 &= ~(MVPP22_CTRL4_RX_FC_EN | MVPP22_CTRL4_TX_FC_EN);
/* Configure port type */
if (phy_interface_mode_is_8023z(state->interface)) {
@@ -5014,31 +5012,20 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
/* Configure negotiation style */
if (!phylink_autoneg_inband(mode)) {
- /* Phy or fixed speed - no in-band AN */
- if (state->duplex)
- an |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
-
- if (state->speed == SPEED_1000 || state->speed == SPEED_2500)
- an |= MVPP2_GMAC_CONFIG_GMII_SPEED;
- else if (state->speed == SPEED_100)
- an |= MVPP2_GMAC_CONFIG_MII_SPEED;
-
- if (state->pause & MLO_PAUSE_TX)
- ctrl4 |= MVPP22_CTRL4_TX_FC_EN;
- if (state->pause & MLO_PAUSE_RX)
- ctrl4 |= MVPP22_CTRL4_RX_FC_EN;
+ /* Phy or fixed speed - no in-band AN, nothing to do, leave the
+ * configured speed, duplex and flow control as-is.
+ */
} else if (state->interface == PHY_INTERFACE_MODE_SGMII) {
/* SGMII in-band mode receives the speed and duplex from
* the PHY. Flow control information is not received. */
- an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN | MVPP2_GMAC_FORCE_LINK_PASS);
+ an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN |
+ MVPP2_GMAC_FORCE_LINK_PASS |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX);
an |= MVPP2_GMAC_IN_BAND_AUTONEG |
MVPP2_GMAC_AN_SPEED_EN |
MVPP2_GMAC_AN_DUPLEX_EN;
-
- 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_8023z(state->interface)) {
/* 1000BaseX and 2500BaseX ports cannot negotiate speed nor can
* they negotiate duplex: they are always operating with a fixed
@@ -5046,19 +5033,17 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
* speed and full duplex here.
*/
ctrl0 |= MVPP2_GMAC_PORT_TYPE_MASK;
- an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN | MVPP2_GMAC_FORCE_LINK_PASS);
+ an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN |
+ MVPP2_GMAC_FORCE_LINK_PASS |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX);
an |= MVPP2_GMAC_IN_BAND_AUTONEG |
MVPP2_GMAC_CONFIG_GMII_SPEED |
MVPP2_GMAC_CONFIG_FULL_DUPLEX;
- if (state->pause & MLO_PAUSE_AN && state->an_enabled) {
+ if (state->pause & MLO_PAUSE_AN && state->an_enabled)
an |= MVPP2_GMAC_FLOW_CTRL_AUTONEG;
- } else {
- if (state->pause & MLO_PAUSE_TX)
- ctrl4 |= MVPP22_CTRL4_TX_FC_EN;
- if (state->pause & MLO_PAUSE_RX)
- ctrl4 |= MVPP22_CTRL4_RX_FC_EN;
- }
}
/* Some fields of the auto-negotiation register require the port to be down when
@@ -5155,18 +5140,44 @@ static void mvpp2_mac_link_up(struct phylink_config *config,
struct mvpp2_port *port = netdev_priv(dev);
u32 val;
- if (!phylink_autoneg_inband(mode)) {
- if (mvpp2_is_xlg(interface)) {
+ if (mvpp2_is_xlg(interface)) {
+ if (!phylink_autoneg_inband(mode)) {
val = readl(port->base + MVPP22_XLG_CTRL0_REG);
val &= ~MVPP22_XLG_CTRL0_FORCE_LINK_DOWN;
val |= MVPP22_XLG_CTRL0_FORCE_LINK_PASS;
writel(val, port->base + MVPP22_XLG_CTRL0_REG);
- } else {
+ }
+ } else {
+ if (!phylink_autoneg_inband(mode)) {
val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val &= ~MVPP2_GMAC_FORCE_LINK_DOWN;
+ val &= ~(MVPP2_GMAC_FORCE_LINK_DOWN |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX);
val |= MVPP2_GMAC_FORCE_LINK_PASS;
+
+ if (speed == SPEED_1000 || speed == SPEED_2500)
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED;
+ else if (speed == SPEED_100)
+ val |= MVPP2_GMAC_CONFIG_MII_SPEED;
+
+ if (duplex == DUPLEX_FULL)
+ val |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+
writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
}
+
+ /* We can always update the flow control enable bits;
+ * these will only be effective if flow control AN
+ * (MVPP2_GMAC_FLOW_CTRL_AUTONEG) is disabled.
+ */
+ val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
+ val &= ~(MVPP22_CTRL4_RX_FC_EN | MVPP22_CTRL4_TX_FC_EN);
+ if (tx_pause)
+ val |= MVPP22_CTRL4_TX_FC_EN;
+ if (rx_pause)
+ val |= MVPP22_CTRL4_RX_FC_EN;
+ writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
}
mvpp2_port_enable(port);
--
2.20.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 8/8] net: mvpp2: use resolved link config in mac_link_up()
@ 2020-02-26 10:24 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Nicolas Ferre, Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Convert the Marvell mvpp2 ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 83 +++++++++++--------
1 file changed, 47 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index ed8042d97e29..6b9c7ed2547e 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4976,15 +4976,13 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
old_ctrl2 = ctrl2 = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
old_ctrl4 = ctrl4 = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
- an &= ~(MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_CONFIG_GMII_SPEED |
- MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_FC_ADV_EN |
+ an &= ~(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_IN_BAND_AUTONEG | MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS);
+ MVPP2_GMAC_AN_DUPLEX_EN | MVPP2_GMAC_IN_BAND_AUTONEG |
+ MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS);
ctrl0 &= ~MVPP2_GMAC_PORT_TYPE_MASK;
ctrl2 &= ~(MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PORT_RESET_MASK |
MVPP2_GMAC_PCS_ENABLE_MASK);
- ctrl4 &= ~(MVPP22_CTRL4_RX_FC_EN | MVPP22_CTRL4_TX_FC_EN);
/* Configure port type */
if (phy_interface_mode_is_8023z(state->interface)) {
@@ -5014,31 +5012,20 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
/* Configure negotiation style */
if (!phylink_autoneg_inband(mode)) {
- /* Phy or fixed speed - no in-band AN */
- if (state->duplex)
- an |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
-
- if (state->speed == SPEED_1000 || state->speed == SPEED_2500)
- an |= MVPP2_GMAC_CONFIG_GMII_SPEED;
- else if (state->speed == SPEED_100)
- an |= MVPP2_GMAC_CONFIG_MII_SPEED;
-
- if (state->pause & MLO_PAUSE_TX)
- ctrl4 |= MVPP22_CTRL4_TX_FC_EN;
- if (state->pause & MLO_PAUSE_RX)
- ctrl4 |= MVPP22_CTRL4_RX_FC_EN;
+ /* Phy or fixed speed - no in-band AN, nothing to do, leave the
+ * configured speed, duplex and flow control as-is.
+ */
} else if (state->interface == PHY_INTERFACE_MODE_SGMII) {
/* SGMII in-band mode receives the speed and duplex from
* the PHY. Flow control information is not received. */
- an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN | MVPP2_GMAC_FORCE_LINK_PASS);
+ an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN |
+ MVPP2_GMAC_FORCE_LINK_PASS |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX);
an |= MVPP2_GMAC_IN_BAND_AUTONEG |
MVPP2_GMAC_AN_SPEED_EN |
MVPP2_GMAC_AN_DUPLEX_EN;
-
- 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_8023z(state->interface)) {
/* 1000BaseX and 2500BaseX ports cannot negotiate speed nor can
* they negotiate duplex: they are always operating with a fixed
@@ -5046,19 +5033,17 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
* speed and full duplex here.
*/
ctrl0 |= MVPP2_GMAC_PORT_TYPE_MASK;
- an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN | MVPP2_GMAC_FORCE_LINK_PASS);
+ an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN |
+ MVPP2_GMAC_FORCE_LINK_PASS |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX);
an |= MVPP2_GMAC_IN_BAND_AUTONEG |
MVPP2_GMAC_CONFIG_GMII_SPEED |
MVPP2_GMAC_CONFIG_FULL_DUPLEX;
- if (state->pause & MLO_PAUSE_AN && state->an_enabled) {
+ if (state->pause & MLO_PAUSE_AN && state->an_enabled)
an |= MVPP2_GMAC_FLOW_CTRL_AUTONEG;
- } else {
- if (state->pause & MLO_PAUSE_TX)
- ctrl4 |= MVPP22_CTRL4_TX_FC_EN;
- if (state->pause & MLO_PAUSE_RX)
- ctrl4 |= MVPP22_CTRL4_RX_FC_EN;
- }
}
/* Some fields of the auto-negotiation register require the port to be down when
@@ -5155,18 +5140,44 @@ static void mvpp2_mac_link_up(struct phylink_config *config,
struct mvpp2_port *port = netdev_priv(dev);
u32 val;
- if (!phylink_autoneg_inband(mode)) {
- if (mvpp2_is_xlg(interface)) {
+ if (mvpp2_is_xlg(interface)) {
+ if (!phylink_autoneg_inband(mode)) {
val = readl(port->base + MVPP22_XLG_CTRL0_REG);
val &= ~MVPP22_XLG_CTRL0_FORCE_LINK_DOWN;
val |= MVPP22_XLG_CTRL0_FORCE_LINK_PASS;
writel(val, port->base + MVPP22_XLG_CTRL0_REG);
- } else {
+ }
+ } else {
+ if (!phylink_autoneg_inband(mode)) {
val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val &= ~MVPP2_GMAC_FORCE_LINK_DOWN;
+ val &= ~(MVPP2_GMAC_FORCE_LINK_DOWN |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX);
val |= MVPP2_GMAC_FORCE_LINK_PASS;
+
+ if (speed == SPEED_1000 || speed == SPEED_2500)
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED;
+ else if (speed == SPEED_100)
+ val |= MVPP2_GMAC_CONFIG_MII_SPEED;
+
+ if (duplex == DUPLEX_FULL)
+ val |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+
writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
}
+
+ /* We can always update the flow control enable bits;
+ * these will only be effective if flow control AN
+ * (MVPP2_GMAC_FLOW_CTRL_AUTONEG) is disabled.
+ */
+ val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
+ val &= ~(MVPP22_CTRL4_RX_FC_EN | MVPP22_CTRL4_TX_FC_EN);
+ if (tx_pause)
+ val |= MVPP22_CTRL4_TX_FC_EN;
+ if (rx_pause)
+ val |= MVPP22_CTRL4_RX_FC_EN;
+ writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
}
mvpp2_port_enable(port);
--
2.20.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH net-next v2 8/8] net: mvpp2: use resolved link config in mac_link_up()
@ 2020-02-26 10:24 ` Russell King
0 siblings, 0 replies; 60+ messages in thread
From: Russell King @ 2020-02-26 10:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: linux-doc, Thomas Petazzoni, Ioana Ciornei, linux-stm32,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, linux-mediatek, John Crispin,
Matthias Brugger, Giuseppe Cavallaro, linux-arm-kernel, netdev,
Vivien Didelot, Maxime Coquelin, Vladimir Oltean,
David S. Miller, Felix Fietkau
Convert the Marvell mvpp2 ethernet driver to use the finalised link
parameters in mac_link_up() rather than the parameters in mac_config().
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 83 +++++++++++--------
1 file changed, 47 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index ed8042d97e29..6b9c7ed2547e 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4976,15 +4976,13 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
old_ctrl2 = ctrl2 = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
old_ctrl4 = ctrl4 = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
- an &= ~(MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_CONFIG_GMII_SPEED |
- MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_FC_ADV_EN |
+ an &= ~(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_IN_BAND_AUTONEG | MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS);
+ MVPP2_GMAC_AN_DUPLEX_EN | MVPP2_GMAC_IN_BAND_AUTONEG |
+ MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS);
ctrl0 &= ~MVPP2_GMAC_PORT_TYPE_MASK;
ctrl2 &= ~(MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PORT_RESET_MASK |
MVPP2_GMAC_PCS_ENABLE_MASK);
- ctrl4 &= ~(MVPP22_CTRL4_RX_FC_EN | MVPP22_CTRL4_TX_FC_EN);
/* Configure port type */
if (phy_interface_mode_is_8023z(state->interface)) {
@@ -5014,31 +5012,20 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
/* Configure negotiation style */
if (!phylink_autoneg_inband(mode)) {
- /* Phy or fixed speed - no in-band AN */
- if (state->duplex)
- an |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
-
- if (state->speed == SPEED_1000 || state->speed == SPEED_2500)
- an |= MVPP2_GMAC_CONFIG_GMII_SPEED;
- else if (state->speed == SPEED_100)
- an |= MVPP2_GMAC_CONFIG_MII_SPEED;
-
- if (state->pause & MLO_PAUSE_TX)
- ctrl4 |= MVPP22_CTRL4_TX_FC_EN;
- if (state->pause & MLO_PAUSE_RX)
- ctrl4 |= MVPP22_CTRL4_RX_FC_EN;
+ /* Phy or fixed speed - no in-band AN, nothing to do, leave the
+ * configured speed, duplex and flow control as-is.
+ */
} else if (state->interface == PHY_INTERFACE_MODE_SGMII) {
/* SGMII in-band mode receives the speed and duplex from
* the PHY. Flow control information is not received. */
- an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN | MVPP2_GMAC_FORCE_LINK_PASS);
+ an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN |
+ MVPP2_GMAC_FORCE_LINK_PASS |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX);
an |= MVPP2_GMAC_IN_BAND_AUTONEG |
MVPP2_GMAC_AN_SPEED_EN |
MVPP2_GMAC_AN_DUPLEX_EN;
-
- 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_8023z(state->interface)) {
/* 1000BaseX and 2500BaseX ports cannot negotiate speed nor can
* they negotiate duplex: they are always operating with a fixed
@@ -5046,19 +5033,17 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
* speed and full duplex here.
*/
ctrl0 |= MVPP2_GMAC_PORT_TYPE_MASK;
- an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN | MVPP2_GMAC_FORCE_LINK_PASS);
+ an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN |
+ MVPP2_GMAC_FORCE_LINK_PASS |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX);
an |= MVPP2_GMAC_IN_BAND_AUTONEG |
MVPP2_GMAC_CONFIG_GMII_SPEED |
MVPP2_GMAC_CONFIG_FULL_DUPLEX;
- if (state->pause & MLO_PAUSE_AN && state->an_enabled) {
+ if (state->pause & MLO_PAUSE_AN && state->an_enabled)
an |= MVPP2_GMAC_FLOW_CTRL_AUTONEG;
- } else {
- if (state->pause & MLO_PAUSE_TX)
- ctrl4 |= MVPP22_CTRL4_TX_FC_EN;
- if (state->pause & MLO_PAUSE_RX)
- ctrl4 |= MVPP22_CTRL4_RX_FC_EN;
- }
}
/* Some fields of the auto-negotiation register require the port to be down when
@@ -5155,18 +5140,44 @@ static void mvpp2_mac_link_up(struct phylink_config *config,
struct mvpp2_port *port = netdev_priv(dev);
u32 val;
- if (!phylink_autoneg_inband(mode)) {
- if (mvpp2_is_xlg(interface)) {
+ if (mvpp2_is_xlg(interface)) {
+ if (!phylink_autoneg_inband(mode)) {
val = readl(port->base + MVPP22_XLG_CTRL0_REG);
val &= ~MVPP22_XLG_CTRL0_FORCE_LINK_DOWN;
val |= MVPP22_XLG_CTRL0_FORCE_LINK_PASS;
writel(val, port->base + MVPP22_XLG_CTRL0_REG);
- } else {
+ }
+ } else {
+ if (!phylink_autoneg_inband(mode)) {
val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val &= ~MVPP2_GMAC_FORCE_LINK_DOWN;
+ val &= ~(MVPP2_GMAC_FORCE_LINK_DOWN |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX);
val |= MVPP2_GMAC_FORCE_LINK_PASS;
+
+ if (speed == SPEED_1000 || speed == SPEED_2500)
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED;
+ else if (speed == SPEED_100)
+ val |= MVPP2_GMAC_CONFIG_MII_SPEED;
+
+ if (duplex == DUPLEX_FULL)
+ val |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+
writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
}
+
+ /* We can always update the flow control enable bits;
+ * these will only be effective if flow control AN
+ * (MVPP2_GMAC_FLOW_CTRL_AUTONEG) is disabled.
+ */
+ val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
+ val &= ~(MVPP22_CTRL4_RX_FC_EN | MVPP22_CTRL4_TX_FC_EN);
+ if (tx_pause)
+ val |= MVPP22_CTRL4_TX_FC_EN;
+ if (rx_pause)
+ val |= MVPP22_CTRL4_RX_FC_EN;
+ writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
}
mvpp2_port_enable(port);
--
2.20.1
_______________________________________________
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] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
2020-02-26 10:23 ` Russell King
(?)
@ 2020-02-26 11:06 ` Vladimir Oltean
-1 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 11:06 UTC (permalink / raw)
To: Russell King
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, Alexandre Torgue,
David S. Miller, Felix Fietkau, Giuseppe Cavallaro,
Hauke Mehrtens, Ioana Ciornei, Jakub Kicinski, John Crispin,
Jonathan Corbet, Jose Abreu,
moderated list:ARM/Mediatek SoC support, Linux Doc Mailing List,
moderated list:ARM/Mediatek SoC support, linux-stm32, Mark Lee,
Matthias Brugger, Maxime Coquelin, Michal Simek, netdev,
Nicolas Ferre, Radhey Shyam Pandey, Sean Wang, Thomas Petazzoni,
Vivien Didelot, Ioana Radulescu
Hi Russell,
On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
>
> Propagate the resolved link parameters via the mac_link_up() call for
> MACs that do not automatically track their PCS state. We propagate the
> link parameters via function arguments so that inappropriate members
> of struct phylink_link_state can't be accessed, and creating a new
> structure just for this adds needless complexity to the API.
>
> Tested-by: Andre Przywara <andre.przywara@arm.com>
> Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> Documentation/networking/sfp-phylink.rst | 17 +++++-
> drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> drivers/net/phy/phylink.c | 9 ++-
> include/linux/phylink.h | 57 ++++++++++++++-----
> net/dsa/port.c | 4 +-
> 11 files changed, 105 insertions(+), 41 deletions(-)
>
> diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> index d753a309f9d1..8d7af28cd835 100644
> --- a/Documentation/networking/sfp-phylink.rst
> +++ b/Documentation/networking/sfp-phylink.rst
> @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> this documentation.
>
> 1. Optionally split the network driver's phylib update function into
> - three parts dealing with link-down, link-up and reconfiguring the
> - MAC settings. This can be done as a separate preparation commit.
> + two parts dealing with link-down and link-up. This can be done as
> + a separate preparation commit.
>
> - An example of this preparation can be found in git commit fc548b991fb0.
> + An older example of this preparation can be found in git commit
> + fc548b991fb0, although this was splitting into three parts; the
> + link-up part now includes configuring the MAC for the link settings.
> + Please see :c:func:`mac_link_up` for more information on this.
>
> 2. Replace::
>
> @@ -207,6 +210,14 @@ this documentation.
> using. This is particularly important for in-band negotiation
> methods such as 1000base-X and SGMII.
>
> + The :c:func:`mac_link_up` method is used to inform the MAC that the
> + link has come up. The call includes the negotiation mode and interface
> + for reference only. The finalised link parameters are also supplied
> + (speed, duplex and flow control/pause enablement settings) which
> + should be used to configure the MAC when the MAC and PCS are not
> + tightly integrated, or when the settings are not coming from in-band
> + negotiation.
> +
> The :c:func:`mac_config` method is used to update the MAC with the
> requested state, and must avoid unnecessarily taking the link down
> when making changes to the MAC configuration. This means the
Just to make sure I understand the changes:
- A MAC with no PCS can be configured in either .mac_config or .mac_link_up
- A MAC that needs to be manually reconfigured to the link mode
negotiated by its PCS needs to have the PCS configured in .mac_config
and the MAC in .mac_link_up
- A MAC with PCS where the MAC follows the PCS negotiation
automatically in hardware is basically equivalent with a MAC with no
PCS, and therefore can be configured in either .mac_config or
.mac_link_up
Is this correct?
Regards,
-Vladimir
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 11:06 ` Vladimir Oltean
0 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 11:06 UTC (permalink / raw)
To: Russell King
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Nicolas Ferre,
Vivien Didelot, Maxime Coquelin, Felix Fietkau, David S. Miller,
Heiner Kallweit
Hi Russell,
On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
>
> Propagate the resolved link parameters via the mac_link_up() call for
> MACs that do not automatically track their PCS state. We propagate the
> link parameters via function arguments so that inappropriate members
> of struct phylink_link_state can't be accessed, and creating a new
> structure just for this adds needless complexity to the API.
>
> Tested-by: Andre Przywara <andre.przywara@arm.com>
> Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> Documentation/networking/sfp-phylink.rst | 17 +++++-
> drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> drivers/net/phy/phylink.c | 9 ++-
> include/linux/phylink.h | 57 ++++++++++++++-----
> net/dsa/port.c | 4 +-
> 11 files changed, 105 insertions(+), 41 deletions(-)
>
> diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> index d753a309f9d1..8d7af28cd835 100644
> --- a/Documentation/networking/sfp-phylink.rst
> +++ b/Documentation/networking/sfp-phylink.rst
> @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> this documentation.
>
> 1. Optionally split the network driver's phylib update function into
> - three parts dealing with link-down, link-up and reconfiguring the
> - MAC settings. This can be done as a separate preparation commit.
> + two parts dealing with link-down and link-up. This can be done as
> + a separate preparation commit.
>
> - An example of this preparation can be found in git commit fc548b991fb0.
> + An older example of this preparation can be found in git commit
> + fc548b991fb0, although this was splitting into three parts; the
> + link-up part now includes configuring the MAC for the link settings.
> + Please see :c:func:`mac_link_up` for more information on this.
>
> 2. Replace::
>
> @@ -207,6 +210,14 @@ this documentation.
> using. This is particularly important for in-band negotiation
> methods such as 1000base-X and SGMII.
>
> + The :c:func:`mac_link_up` method is used to inform the MAC that the
> + link has come up. The call includes the negotiation mode and interface
> + for reference only. The finalised link parameters are also supplied
> + (speed, duplex and flow control/pause enablement settings) which
> + should be used to configure the MAC when the MAC and PCS are not
> + tightly integrated, or when the settings are not coming from in-band
> + negotiation.
> +
> The :c:func:`mac_config` method is used to update the MAC with the
> requested state, and must avoid unnecessarily taking the link down
> when making changes to the MAC configuration. This means the
Just to make sure I understand the changes:
- A MAC with no PCS can be configured in either .mac_config or .mac_link_up
- A MAC that needs to be manually reconfigured to the link mode
negotiated by its PCS needs to have the PCS configured in .mac_config
and the MAC in .mac_link_up
- A MAC with PCS where the MAC follows the PCS negotiation
automatically in hardware is basically equivalent with a MAC with no
PCS, and therefore can be configured in either .mac_config or
.mac_link_up
Is this correct?
Regards,
-Vladimir
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 11:06 ` Vladimir Oltean
0 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 11:06 UTC (permalink / raw)
To: Russell King
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
Hi Russell,
On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
>
> Propagate the resolved link parameters via the mac_link_up() call for
> MACs that do not automatically track their PCS state. We propagate the
> link parameters via function arguments so that inappropriate members
> of struct phylink_link_state can't be accessed, and creating a new
> structure just for this adds needless complexity to the API.
>
> Tested-by: Andre Przywara <andre.przywara@arm.com>
> Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> Documentation/networking/sfp-phylink.rst | 17 +++++-
> drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> drivers/net/phy/phylink.c | 9 ++-
> include/linux/phylink.h | 57 ++++++++++++++-----
> net/dsa/port.c | 4 +-
> 11 files changed, 105 insertions(+), 41 deletions(-)
>
> diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> index d753a309f9d1..8d7af28cd835 100644
> --- a/Documentation/networking/sfp-phylink.rst
> +++ b/Documentation/networking/sfp-phylink.rst
> @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> this documentation.
>
> 1. Optionally split the network driver's phylib update function into
> - three parts dealing with link-down, link-up and reconfiguring the
> - MAC settings. This can be done as a separate preparation commit.
> + two parts dealing with link-down and link-up. This can be done as
> + a separate preparation commit.
>
> - An example of this preparation can be found in git commit fc548b991fb0.
> + An older example of this preparation can be found in git commit
> + fc548b991fb0, although this was splitting into three parts; the
> + link-up part now includes configuring the MAC for the link settings.
> + Please see :c:func:`mac_link_up` for more information on this.
>
> 2. Replace::
>
> @@ -207,6 +210,14 @@ this documentation.
> using. This is particularly important for in-band negotiation
> methods such as 1000base-X and SGMII.
>
> + The :c:func:`mac_link_up` method is used to inform the MAC that the
> + link has come up. The call includes the negotiation mode and interface
> + for reference only. The finalised link parameters are also supplied
> + (speed, duplex and flow control/pause enablement settings) which
> + should be used to configure the MAC when the MAC and PCS are not
> + tightly integrated, or when the settings are not coming from in-band
> + negotiation.
> +
> The :c:func:`mac_config` method is used to update the MAC with the
> requested state, and must avoid unnecessarily taking the link down
> when making changes to the MAC configuration. This means the
Just to make sure I understand the changes:
- A MAC with no PCS can be configured in either .mac_config or .mac_link_up
- A MAC that needs to be manually reconfigured to the link mode
negotiated by its PCS needs to have the PCS configured in .mac_config
and the MAC in .mac_link_up
- A MAC with PCS where the MAC follows the PCS negotiation
automatically in hardware is basically equivalent with a MAC with no
PCS, and therefore can be configured in either .mac_config or
.mac_link_up
Is this correct?
Regards,
-Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
2020-02-26 11:06 ` Vladimir Oltean
(?)
@ 2020-02-26 11:55 ` Russell King - ARM Linux admin
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 11:55 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote:
> Hi Russell,
>
> On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> >
> > Propagate the resolved link parameters via the mac_link_up() call for
> > MACs that do not automatically track their PCS state. We propagate the
> > link parameters via function arguments so that inappropriate members
> > of struct phylink_link_state can't be accessed, and creating a new
> > structure just for this adds needless complexity to the API.
> >
> > Tested-by: Andre Przywara <andre.przywara@arm.com>
> > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> > Documentation/networking/sfp-phylink.rst | 17 +++++-
> > drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> > drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> > drivers/net/phy/phylink.c | 9 ++-
> > include/linux/phylink.h | 57 ++++++++++++++-----
> > net/dsa/port.c | 4 +-
> > 11 files changed, 105 insertions(+), 41 deletions(-)
> >
> > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> > index d753a309f9d1..8d7af28cd835 100644
> > --- a/Documentation/networking/sfp-phylink.rst
> > +++ b/Documentation/networking/sfp-phylink.rst
> > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> > this documentation.
> >
> > 1. Optionally split the network driver's phylib update function into
> > - three parts dealing with link-down, link-up and reconfiguring the
> > - MAC settings. This can be done as a separate preparation commit.
> > + two parts dealing with link-down and link-up. This can be done as
> > + a separate preparation commit.
> >
> > - An example of this preparation can be found in git commit fc548b991fb0.
> > + An older example of this preparation can be found in git commit
> > + fc548b991fb0, although this was splitting into three parts; the
> > + link-up part now includes configuring the MAC for the link settings.
> > + Please see :c:func:`mac_link_up` for more information on this.
> >
> > 2. Replace::
> >
> > @@ -207,6 +210,14 @@ this documentation.
> > using. This is particularly important for in-band negotiation
> > methods such as 1000base-X and SGMII.
> >
> > + The :c:func:`mac_link_up` method is used to inform the MAC that the
> > + link has come up. The call includes the negotiation mode and interface
> > + for reference only. The finalised link parameters are also supplied
> > + (speed, duplex and flow control/pause enablement settings) which
> > + should be used to configure the MAC when the MAC and PCS are not
> > + tightly integrated, or when the settings are not coming from in-band
> > + negotiation.
> > +
> > The :c:func:`mac_config` method is used to update the MAC with the
> > requested state, and must avoid unnecessarily taking the link down
> > when making changes to the MAC configuration. This means the
>
> Just to make sure I understand the changes:
> - A MAC with no PCS can be configured in either .mac_config or .mac_link_up
I would much prefer mac_link_up to be used for setting the speed,
duplex and pause modes for future-proofing in all cases except for
the case where these parameters are automatically updated in the
MAC from its associated PCS.
mac_link_up must not be used to configure the AN mode or interface
mode; these must be configured in mac_config().
> - A MAC that needs to be manually reconfigured to the link mode
> negotiated by its PCS needs to have the PCS configured in .mac_config
> and the MAC in .mac_link_up
I do have further changes that split the PCS ops from the MAC ops, so
what is in this series is not the full story yet - some of the further
patches can be found in my "phy" branch and "cex7" branches where I add
support to dpaa2 for automatically switching between SGMII and
1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the
extra complication that there's a firmware layer between the PCS and
MAC.
However, this series is the first stand-alone step along the road to
supporting split PCS/MAC setups in a sane manner.
I discussed with Andrew Lunn how much to send, and the conclusion was
to make the changes in a number of small patch series, as large patch
series tend not to get reviewed. My experience with _this_ series is
that even this is very difficult to get feedback for, so adding any
additional patches will just make that worse.
> - A MAC with PCS where the MAC follows the PCS negotiation
> automatically in hardware is basically equivalent with a MAC with no
> PCS, and therefore can be configured in either .mac_config or
> .mac_link_up
In this case, mac_link_up doesn't do anything with the speed/duplex/
pause stuff when those are automatically passed from the PCS.
I'm afraid that sentence contains a subtlety that's going to get
people: it is not clear cut because of the different natures of the
various links.
In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the
duplex and pause with the remote end. For mvneta (an example of a
combined PCS/MAC implementation) operating in-band:
- In mac_config():
- configures for 1000BASE-X interface type with in-band AN.
- configures fixed 1G.
- As mvneta only supports full duplex, we disable duplex negotiation
and force full duplex.
- Only symmetric pause is supported, and we set the symmetric pause
advertisement appropriately, with pause negotiation enabled.
- In mac_link_up():
- merely allow the device to transmit and receive.
The MAC will be forced to 1G, full duplex, and will automatically be
configured by the PCS for pause support depending on the hardware
based pause resolution.
The situation is different for SGMII operating in-band:
- In mac_config():
- configures for SGMII interface type with in-band AN.
- configures speed and duplex negotiation.
- disables pause negotiation; SGMII has no support for this.
- In mac_link_up():
- enables or disables pause frames depending on the tx_pause/
rx_pause flags, since this is not available from the MAC.
- allow the device to transmit and receive.
If we aren't operating in in-band mode, then:
- In mac_config():
- configures for the interface type without in-band AN.
- disables speed, duplex and pause negotiation.
- In mac_link_up():
- sets the speed, duplex and pause frames depending on the passed
parameters.
- allow the device to transmit and receive.
Please see patch 7 of this series which implements this for mvneta.
So, there is a split between what mac_config() should be doing and what
mac_link_up() should be doing; this is why I've said in the
documentation that the "mode" and "interface" are for reference only in
mac_link_up() - mac_link_up() can use these to decide _how_ to program
the resolved parameters, but should _not_ use them to determine the
link configuration (such as changing the interface between SGMII and
1000BASE-X - that is the responsibility of mac_config().)
I hope that helps clarify the situation.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 11:55 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 11:55 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Heiner Kallweit, David S. Miller, Felix Fietkau
On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote:
> Hi Russell,
>
> On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> >
> > Propagate the resolved link parameters via the mac_link_up() call for
> > MACs that do not automatically track their PCS state. We propagate the
> > link parameters via function arguments so that inappropriate members
> > of struct phylink_link_state can't be accessed, and creating a new
> > structure just for this adds needless complexity to the API.
> >
> > Tested-by: Andre Przywara <andre.przywara@arm.com>
> > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> > Documentation/networking/sfp-phylink.rst | 17 +++++-
> > drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> > drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> > drivers/net/phy/phylink.c | 9 ++-
> > include/linux/phylink.h | 57 ++++++++++++++-----
> > net/dsa/port.c | 4 +-
> > 11 files changed, 105 insertions(+), 41 deletions(-)
> >
> > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> > index d753a309f9d1..8d7af28cd835 100644
> > --- a/Documentation/networking/sfp-phylink.rst
> > +++ b/Documentation/networking/sfp-phylink.rst
> > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> > this documentation.
> >
> > 1. Optionally split the network driver's phylib update function into
> > - three parts dealing with link-down, link-up and reconfiguring the
> > - MAC settings. This can be done as a separate preparation commit.
> > + two parts dealing with link-down and link-up. This can be done as
> > + a separate preparation commit.
> >
> > - An example of this preparation can be found in git commit fc548b991fb0.
> > + An older example of this preparation can be found in git commit
> > + fc548b991fb0, although this was splitting into three parts; the
> > + link-up part now includes configuring the MAC for the link settings.
> > + Please see :c:func:`mac_link_up` for more information on this.
> >
> > 2. Replace::
> >
> > @@ -207,6 +210,14 @@ this documentation.
> > using. This is particularly important for in-band negotiation
> > methods such as 1000base-X and SGMII.
> >
> > + The :c:func:`mac_link_up` method is used to inform the MAC that the
> > + link has come up. The call includes the negotiation mode and interface
> > + for reference only. The finalised link parameters are also supplied
> > + (speed, duplex and flow control/pause enablement settings) which
> > + should be used to configure the MAC when the MAC and PCS are not
> > + tightly integrated, or when the settings are not coming from in-band
> > + negotiation.
> > +
> > The :c:func:`mac_config` method is used to update the MAC with the
> > requested state, and must avoid unnecessarily taking the link down
> > when making changes to the MAC configuration. This means the
>
> Just to make sure I understand the changes:
> - A MAC with no PCS can be configured in either .mac_config or .mac_link_up
I would much prefer mac_link_up to be used for setting the speed,
duplex and pause modes for future-proofing in all cases except for
the case where these parameters are automatically updated in the
MAC from its associated PCS.
mac_link_up must not be used to configure the AN mode or interface
mode; these must be configured in mac_config().
> - A MAC that needs to be manually reconfigured to the link mode
> negotiated by its PCS needs to have the PCS configured in .mac_config
> and the MAC in .mac_link_up
I do have further changes that split the PCS ops from the MAC ops, so
what is in this series is not the full story yet - some of the further
patches can be found in my "phy" branch and "cex7" branches where I add
support to dpaa2 for automatically switching between SGMII and
1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the
extra complication that there's a firmware layer between the PCS and
MAC.
However, this series is the first stand-alone step along the road to
supporting split PCS/MAC setups in a sane manner.
I discussed with Andrew Lunn how much to send, and the conclusion was
to make the changes in a number of small patch series, as large patch
series tend not to get reviewed. My experience with _this_ series is
that even this is very difficult to get feedback for, so adding any
additional patches will just make that worse.
> - A MAC with PCS where the MAC follows the PCS negotiation
> automatically in hardware is basically equivalent with a MAC with no
> PCS, and therefore can be configured in either .mac_config or
> .mac_link_up
In this case, mac_link_up doesn't do anything with the speed/duplex/
pause stuff when those are automatically passed from the PCS.
I'm afraid that sentence contains a subtlety that's going to get
people: it is not clear cut because of the different natures of the
various links.
In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the
duplex and pause with the remote end. For mvneta (an example of a
combined PCS/MAC implementation) operating in-band:
- In mac_config():
- configures for 1000BASE-X interface type with in-band AN.
- configures fixed 1G.
- As mvneta only supports full duplex, we disable duplex negotiation
and force full duplex.
- Only symmetric pause is supported, and we set the symmetric pause
advertisement appropriately, with pause negotiation enabled.
- In mac_link_up():
- merely allow the device to transmit and receive.
The MAC will be forced to 1G, full duplex, and will automatically be
configured by the PCS for pause support depending on the hardware
based pause resolution.
The situation is different for SGMII operating in-band:
- In mac_config():
- configures for SGMII interface type with in-band AN.
- configures speed and duplex negotiation.
- disables pause negotiation; SGMII has no support for this.
- In mac_link_up():
- enables or disables pause frames depending on the tx_pause/
rx_pause flags, since this is not available from the MAC.
- allow the device to transmit and receive.
If we aren't operating in in-band mode, then:
- In mac_config():
- configures for the interface type without in-band AN.
- disables speed, duplex and pause negotiation.
- In mac_link_up():
- sets the speed, duplex and pause frames depending on the passed
parameters.
- allow the device to transmit and receive.
Please see patch 7 of this series which implements this for mvneta.
So, there is a split between what mac_config() should be doing and what
mac_link_up() should be doing; this is why I've said in the
documentation that the "mode" and "interface" are for reference only in
mac_link_up() - mac_link_up() can use these to decide _how_ to program
the resolved parameters, but should _not_ use them to determine the
link configuration (such as changing the interface between SGMII and
1000BASE-X - that is the responsibility of mac_config().)
I hope that helps clarify the situation.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 11:55 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 11:55 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Heiner Kallweit, David S. Miller, Felix Fietkau
On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote:
> Hi Russell,
>
> On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> >
> > Propagate the resolved link parameters via the mac_link_up() call for
> > MACs that do not automatically track their PCS state. We propagate the
> > link parameters via function arguments so that inappropriate members
> > of struct phylink_link_state can't be accessed, and creating a new
> > structure just for this adds needless complexity to the API.
> >
> > Tested-by: Andre Przywara <andre.przywara@arm.com>
> > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> > Documentation/networking/sfp-phylink.rst | 17 +++++-
> > drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> > drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> > drivers/net/phy/phylink.c | 9 ++-
> > include/linux/phylink.h | 57 ++++++++++++++-----
> > net/dsa/port.c | 4 +-
> > 11 files changed, 105 insertions(+), 41 deletions(-)
> >
> > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> > index d753a309f9d1..8d7af28cd835 100644
> > --- a/Documentation/networking/sfp-phylink.rst
> > +++ b/Documentation/networking/sfp-phylink.rst
> > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> > this documentation.
> >
> > 1. Optionally split the network driver's phylib update function into
> > - three parts dealing with link-down, link-up and reconfiguring the
> > - MAC settings. This can be done as a separate preparation commit.
> > + two parts dealing with link-down and link-up. This can be done as
> > + a separate preparation commit.
> >
> > - An example of this preparation can be found in git commit fc548b991fb0.
> > + An older example of this preparation can be found in git commit
> > + fc548b991fb0, although this was splitting into three parts; the
> > + link-up part now includes configuring the MAC for the link settings.
> > + Please see :c:func:`mac_link_up` for more information on this.
> >
> > 2. Replace::
> >
> > @@ -207,6 +210,14 @@ this documentation.
> > using. This is particularly important for in-band negotiation
> > methods such as 1000base-X and SGMII.
> >
> > + The :c:func:`mac_link_up` method is used to inform the MAC that the
> > + link has come up. The call includes the negotiation mode and interface
> > + for reference only. The finalised link parameters are also supplied
> > + (speed, duplex and flow control/pause enablement settings) which
> > + should be used to configure the MAC when the MAC and PCS are not
> > + tightly integrated, or when the settings are not coming from in-band
> > + negotiation.
> > +
> > The :c:func:`mac_config` method is used to update the MAC with the
> > requested state, and must avoid unnecessarily taking the link down
> > when making changes to the MAC configuration. This means the
>
> Just to make sure I understand the changes:
> - A MAC with no PCS can be configured in either .mac_config or .mac_link_up
I would much prefer mac_link_up to be used for setting the speed,
duplex and pause modes for future-proofing in all cases except for
the case where these parameters are automatically updated in the
MAC from its associated PCS.
mac_link_up must not be used to configure the AN mode or interface
mode; these must be configured in mac_config().
> - A MAC that needs to be manually reconfigured to the link mode
> negotiated by its PCS needs to have the PCS configured in .mac_config
> and the MAC in .mac_link_up
I do have further changes that split the PCS ops from the MAC ops, so
what is in this series is not the full story yet - some of the further
patches can be found in my "phy" branch and "cex7" branches where I add
support to dpaa2 for automatically switching between SGMII and
1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the
extra complication that there's a firmware layer between the PCS and
MAC.
However, this series is the first stand-alone step along the road to
supporting split PCS/MAC setups in a sane manner.
I discussed with Andrew Lunn how much to send, and the conclusion was
to make the changes in a number of small patch series, as large patch
series tend not to get reviewed. My experience with _this_ series is
that even this is very difficult to get feedback for, so adding any
additional patches will just make that worse.
> - A MAC with PCS where the MAC follows the PCS negotiation
> automatically in hardware is basically equivalent with a MAC with no
> PCS, and therefore can be configured in either .mac_config or
> .mac_link_up
In this case, mac_link_up doesn't do anything with the speed/duplex/
pause stuff when those are automatically passed from the PCS.
I'm afraid that sentence contains a subtlety that's going to get
people: it is not clear cut because of the different natures of the
various links.
In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the
duplex and pause with the remote end. For mvneta (an example of a
combined PCS/MAC implementation) operating in-band:
- In mac_config():
- configures for 1000BASE-X interface type with in-band AN.
- configures fixed 1G.
- As mvneta only supports full duplex, we disable duplex negotiation
and force full duplex.
- Only symmetric pause is supported, and we set the symmetric pause
advertisement appropriately, with pause negotiation enabled.
- In mac_link_up():
- merely allow the device to transmit and receive.
The MAC will be forced to 1G, full duplex, and will automatically be
configured by the PCS for pause support depending on the hardware
based pause resolution.
The situation is different for SGMII operating in-band:
- In mac_config():
- configures for SGMII interface type with in-band AN.
- configures speed and duplex negotiation.
- disables pause negotiation; SGMII has no support for this.
- In mac_link_up():
- enables or disables pause frames depending on the tx_pause/
rx_pause flags, since this is not available from the MAC.
- allow the device to transmit and receive.
If we aren't operating in in-band mode, then:
- In mac_config():
- configures for the interface type without in-band AN.
- disables speed, duplex and pause negotiation.
- In mac_link_up():
- sets the speed, duplex and pause frames depending on the passed
parameters.
- allow the device to transmit and receive.
Please see patch 7 of this series which implements this for mvneta.
So, there is a split between what mac_config() should be doing and what
mac_link_up() should be doing; this is why I've said in the
documentation that the "mode" and "interface" are for reference only in
mac_link_up() - mac_link_up() can use these to decide _how_ to program
the resolved parameters, but should _not_ use them to determine the
link configuration (such as changing the interface between SGMII and
1000BASE-X - that is the responsibility of mac_config().)
I hope that helps clarify the situation.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
2020-02-26 11:55 ` Russell King - ARM Linux admin
(?)
@ 2020-02-26 13:00 ` Vladimir Oltean
-1 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 13:00 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
On Wed, 26 Feb 2020 at 13:56, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote:
> > Hi Russell,
> >
> > On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > >
> > > Propagate the resolved link parameters via the mac_link_up() call for
> > > MACs that do not automatically track their PCS state. We propagate the
> > > link parameters via function arguments so that inappropriate members
> > > of struct phylink_link_state can't be accessed, and creating a new
> > > structure just for this adds needless complexity to the API.
> > >
> > > Tested-by: Andre Przywara <andre.przywara@arm.com>
> > > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > ---
> > > Documentation/networking/sfp-phylink.rst | 17 +++++-
> > > drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> > > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> > > drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> > > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> > > drivers/net/phy/phylink.c | 9 ++-
> > > include/linux/phylink.h | 57 ++++++++++++++-----
> > > net/dsa/port.c | 4 +-
> > > 11 files changed, 105 insertions(+), 41 deletions(-)
> > >
> > > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> > > index d753a309f9d1..8d7af28cd835 100644
> > > --- a/Documentation/networking/sfp-phylink.rst
> > > +++ b/Documentation/networking/sfp-phylink.rst
> > > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> > > this documentation.
> > >
> > > 1. Optionally split the network driver's phylib update function into
> > > - three parts dealing with link-down, link-up and reconfiguring the
> > > - MAC settings. This can be done as a separate preparation commit.
> > > + two parts dealing with link-down and link-up. This can be done as
> > > + a separate preparation commit.
> > >
> > > - An example of this preparation can be found in git commit fc548b991fb0.
> > > + An older example of this preparation can be found in git commit
> > > + fc548b991fb0, although this was splitting into three parts; the
> > > + link-up part now includes configuring the MAC for the link settings.
> > > + Please see :c:func:`mac_link_up` for more information on this.
> > >
> > > 2. Replace::
> > >
> > > @@ -207,6 +210,14 @@ this documentation.
> > > using. This is particularly important for in-band negotiation
> > > methods such as 1000base-X and SGMII.
> > >
> > > + The :c:func:`mac_link_up` method is used to inform the MAC that the
> > > + link has come up. The call includes the negotiation mode and interface
> > > + for reference only. The finalised link parameters are also supplied
> > > + (speed, duplex and flow control/pause enablement settings) which
> > > + should be used to configure the MAC when the MAC and PCS are not
> > > + tightly integrated, or when the settings are not coming from in-band
> > > + negotiation.
> > > +
> > > The :c:func:`mac_config` method is used to update the MAC with the
> > > requested state, and must avoid unnecessarily taking the link down
> > > when making changes to the MAC configuration. This means the
> >
> > Just to make sure I understand the changes:
> > - A MAC with no PCS can be configured in either .mac_config or .mac_link_up
>
> I would much prefer mac_link_up to be used for setting the speed,
> duplex and pause modes for future-proofing in all cases except for
> the case where these parameters are automatically updated in the
> MAC from its associated PCS.
>
> mac_link_up must not be used to configure the AN mode or interface
> mode; these must be configured in mac_config().
>
> > - A MAC that needs to be manually reconfigured to the link mode
> > negotiated by its PCS needs to have the PCS configured in .mac_config
> > and the MAC in .mac_link_up
>
> I do have further changes that split the PCS ops from the MAC ops, so
> what is in this series is not the full story yet - some of the further
> patches can be found in my "phy" branch and "cex7" branches where I add
> support to dpaa2 for automatically switching between SGMII and
> 1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the
> extra complication that there's a firmware layer between the PCS and
> MAC.
>
> However, this series is the first stand-alone step along the road to
> supporting split PCS/MAC setups in a sane manner.
>
> I discussed with Andrew Lunn how much to send, and the conclusion was
> to make the changes in a number of small patch series, as large patch
> series tend not to get reviewed. My experience with _this_ series is
> that even this is very difficult to get feedback for, so adding any
> additional patches will just make that worse.
>
> > - A MAC with PCS where the MAC follows the PCS negotiation
> > automatically in hardware is basically equivalent with a MAC with no
> > PCS, and therefore can be configured in either .mac_config or
> > .mac_link_up
>
> In this case, mac_link_up doesn't do anything with the speed/duplex/
> pause stuff when those are automatically passed from the PCS.
>
> I'm afraid that sentence contains a subtlety that's going to get
> people: it is not clear cut because of the different natures of the
> various links.
>
> In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the
> duplex and pause with the remote end. For mvneta (an example of a
> combined PCS/MAC implementation) operating in-band:
> - In mac_config():
> - configures for 1000BASE-X interface type with in-band AN.
> - configures fixed 1G.
> - As mvneta only supports full duplex, we disable duplex negotiation
> and force full duplex.
> - Only symmetric pause is supported, and we set the symmetric pause
> advertisement appropriately, with pause negotiation enabled.
> - In mac_link_up():
> - merely allow the device to transmit and receive.
>
> The MAC will be forced to 1G, full duplex, and will automatically be
> configured by the PCS for pause support depending on the hardware
> based pause resolution.
>
> The situation is different for SGMII operating in-band:
> - In mac_config():
> - configures for SGMII interface type with in-band AN.
> - configures speed and duplex negotiation.
> - disables pause negotiation; SGMII has no support for this.
> - In mac_link_up():
> - enables or disables pause frames depending on the tx_pause/
> rx_pause flags, since this is not available from the MAC.
> - allow the device to transmit and receive.
>
> If we aren't operating in in-band mode, then:
> - In mac_config():
> - configures for the interface type without in-band AN.
> - disables speed, duplex and pause negotiation.
> - In mac_link_up():
> - sets the speed, duplex and pause frames depending on the passed
> parameters.
But there shouldn't be any requirement for this to be configured at
this step and not earlier?
> - allow the device to transmit and receive.
>
> Please see patch 7 of this series which implements this for mvneta.
>
> So, there is a split between what mac_config() should be doing and what
> mac_link_up() should be doing; this is why I've said in the
> documentation that the "mode" and "interface" are for reference only in
> mac_link_up() - mac_link_up() can use these to decide _how_ to program
> the resolved parameters, but should _not_ use them to determine the
> link configuration (such as changing the interface between SGMII and
> 1000BASE-X - that is the responsibility of mac_config().)
Does any driver currently make any use of the phy_interface_t argument
provided as reference in .mac_link_up?
>
> I hope that helps clarify the situation.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
Ok, so basically what is known early, as well as whatever is needed
for the in-band AN preparation, is configured in .mac_config and what
is known late is configured in .mac_link_up.
Except that you would like to slowly move everything MAC-related to
.mac_link_up, and everything PCS-related to .mac_config, presumably in
an effort to convert .mac_config to .pcs_config and .mac_link_up to
.mac_config. I don't actually know what other patches you have in the
cex7 branch you mentioned. Please consider that people don't
necessarily bookmark your git trees. I've spent some good 10 minutes
searching for the "cex7" and "phy" keywords in emails received from
you, and haven't found the git links.
Regards,
-Vladimir
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 13:00 ` Vladimir Oltean
0 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 13:00 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Heiner Kallweit, David S. Miller, Felix Fietkau
On Wed, 26 Feb 2020 at 13:56, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote:
> > Hi Russell,
> >
> > On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > >
> > > Propagate the resolved link parameters via the mac_link_up() call for
> > > MACs that do not automatically track their PCS state. We propagate the
> > > link parameters via function arguments so that inappropriate members
> > > of struct phylink_link_state can't be accessed, and creating a new
> > > structure just for this adds needless complexity to the API.
> > >
> > > Tested-by: Andre Przywara <andre.przywara@arm.com>
> > > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > ---
> > > Documentation/networking/sfp-phylink.rst | 17 +++++-
> > > drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> > > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> > > drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> > > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> > > drivers/net/phy/phylink.c | 9 ++-
> > > include/linux/phylink.h | 57 ++++++++++++++-----
> > > net/dsa/port.c | 4 +-
> > > 11 files changed, 105 insertions(+), 41 deletions(-)
> > >
> > > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> > > index d753a309f9d1..8d7af28cd835 100644
> > > --- a/Documentation/networking/sfp-phylink.rst
> > > +++ b/Documentation/networking/sfp-phylink.rst
> > > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> > > this documentation.
> > >
> > > 1. Optionally split the network driver's phylib update function into
> > > - three parts dealing with link-down, link-up and reconfiguring the
> > > - MAC settings. This can be done as a separate preparation commit.
> > > + two parts dealing with link-down and link-up. This can be done as
> > > + a separate preparation commit.
> > >
> > > - An example of this preparation can be found in git commit fc548b991fb0.
> > > + An older example of this preparation can be found in git commit
> > > + fc548b991fb0, although this was splitting into three parts; the
> > > + link-up part now includes configuring the MAC for the link settings.
> > > + Please see :c:func:`mac_link_up` for more information on this.
> > >
> > > 2. Replace::
> > >
> > > @@ -207,6 +210,14 @@ this documentation.
> > > using. This is particularly important for in-band negotiation
> > > methods such as 1000base-X and SGMII.
> > >
> > > + The :c:func:`mac_link_up` method is used to inform the MAC that the
> > > + link has come up. The call includes the negotiation mode and interface
> > > + for reference only. The finalised link parameters are also supplied
> > > + (speed, duplex and flow control/pause enablement settings) which
> > > + should be used to configure the MAC when the MAC and PCS are not
> > > + tightly integrated, or when the settings are not coming from in-band
> > > + negotiation.
> > > +
> > > The :c:func:`mac_config` method is used to update the MAC with the
> > > requested state, and must avoid unnecessarily taking the link down
> > > when making changes to the MAC configuration. This means the
> >
> > Just to make sure I understand the changes:
> > - A MAC with no PCS can be configured in either .mac_config or .mac_link_up
>
> I would much prefer mac_link_up to be used for setting the speed,
> duplex and pause modes for future-proofing in all cases except for
> the case where these parameters are automatically updated in the
> MAC from its associated PCS.
>
> mac_link_up must not be used to configure the AN mode or interface
> mode; these must be configured in mac_config().
>
> > - A MAC that needs to be manually reconfigured to the link mode
> > negotiated by its PCS needs to have the PCS configured in .mac_config
> > and the MAC in .mac_link_up
>
> I do have further changes that split the PCS ops from the MAC ops, so
> what is in this series is not the full story yet - some of the further
> patches can be found in my "phy" branch and "cex7" branches where I add
> support to dpaa2 for automatically switching between SGMII and
> 1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the
> extra complication that there's a firmware layer between the PCS and
> MAC.
>
> However, this series is the first stand-alone step along the road to
> supporting split PCS/MAC setups in a sane manner.
>
> I discussed with Andrew Lunn how much to send, and the conclusion was
> to make the changes in a number of small patch series, as large patch
> series tend not to get reviewed. My experience with _this_ series is
> that even this is very difficult to get feedback for, so adding any
> additional patches will just make that worse.
>
> > - A MAC with PCS where the MAC follows the PCS negotiation
> > automatically in hardware is basically equivalent with a MAC with no
> > PCS, and therefore can be configured in either .mac_config or
> > .mac_link_up
>
> In this case, mac_link_up doesn't do anything with the speed/duplex/
> pause stuff when those are automatically passed from the PCS.
>
> I'm afraid that sentence contains a subtlety that's going to get
> people: it is not clear cut because of the different natures of the
> various links.
>
> In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the
> duplex and pause with the remote end. For mvneta (an example of a
> combined PCS/MAC implementation) operating in-band:
> - In mac_config():
> - configures for 1000BASE-X interface type with in-band AN.
> - configures fixed 1G.
> - As mvneta only supports full duplex, we disable duplex negotiation
> and force full duplex.
> - Only symmetric pause is supported, and we set the symmetric pause
> advertisement appropriately, with pause negotiation enabled.
> - In mac_link_up():
> - merely allow the device to transmit and receive.
>
> The MAC will be forced to 1G, full duplex, and will automatically be
> configured by the PCS for pause support depending on the hardware
> based pause resolution.
>
> The situation is different for SGMII operating in-band:
> - In mac_config():
> - configures for SGMII interface type with in-band AN.
> - configures speed and duplex negotiation.
> - disables pause negotiation; SGMII has no support for this.
> - In mac_link_up():
> - enables or disables pause frames depending on the tx_pause/
> rx_pause flags, since this is not available from the MAC.
> - allow the device to transmit and receive.
>
> If we aren't operating in in-band mode, then:
> - In mac_config():
> - configures for the interface type without in-band AN.
> - disables speed, duplex and pause negotiation.
> - In mac_link_up():
> - sets the speed, duplex and pause frames depending on the passed
> parameters.
But there shouldn't be any requirement for this to be configured at
this step and not earlier?
> - allow the device to transmit and receive.
>
> Please see patch 7 of this series which implements this for mvneta.
>
> So, there is a split between what mac_config() should be doing and what
> mac_link_up() should be doing; this is why I've said in the
> documentation that the "mode" and "interface" are for reference only in
> mac_link_up() - mac_link_up() can use these to decide _how_ to program
> the resolved parameters, but should _not_ use them to determine the
> link configuration (such as changing the interface between SGMII and
> 1000BASE-X - that is the responsibility of mac_config().)
Does any driver currently make any use of the phy_interface_t argument
provided as reference in .mac_link_up?
>
> I hope that helps clarify the situation.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
Ok, so basically what is known early, as well as whatever is needed
for the in-band AN preparation, is configured in .mac_config and what
is known late is configured in .mac_link_up.
Except that you would like to slowly move everything MAC-related to
.mac_link_up, and everything PCS-related to .mac_config, presumably in
an effort to convert .mac_config to .pcs_config and .mac_link_up to
.mac_config. I don't actually know what other patches you have in the
cex7 branch you mentioned. Please consider that people don't
necessarily bookmark your git trees. I've spent some good 10 minutes
searching for the "cex7" and "phy" keywords in emails received from
you, and haven't found the git links.
Regards,
-Vladimir
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 13:00 ` Vladimir Oltean
0 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 13:00 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Heiner Kallweit, David S. Miller, Felix Fietkau
On Wed, 26 Feb 2020 at 13:56, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote:
> > Hi Russell,
> >
> > On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > >
> > > Propagate the resolved link parameters via the mac_link_up() call for
> > > MACs that do not automatically track their PCS state. We propagate the
> > > link parameters via function arguments so that inappropriate members
> > > of struct phylink_link_state can't be accessed, and creating a new
> > > structure just for this adds needless complexity to the API.
> > >
> > > Tested-by: Andre Przywara <andre.przywara@arm.com>
> > > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > ---
> > > Documentation/networking/sfp-phylink.rst | 17 +++++-
> > > drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> > > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> > > drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> > > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> > > drivers/net/phy/phylink.c | 9 ++-
> > > include/linux/phylink.h | 57 ++++++++++++++-----
> > > net/dsa/port.c | 4 +-
> > > 11 files changed, 105 insertions(+), 41 deletions(-)
> > >
> > > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> > > index d753a309f9d1..8d7af28cd835 100644
> > > --- a/Documentation/networking/sfp-phylink.rst
> > > +++ b/Documentation/networking/sfp-phylink.rst
> > > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> > > this documentation.
> > >
> > > 1. Optionally split the network driver's phylib update function into
> > > - three parts dealing with link-down, link-up and reconfiguring the
> > > - MAC settings. This can be done as a separate preparation commit.
> > > + two parts dealing with link-down and link-up. This can be done as
> > > + a separate preparation commit.
> > >
> > > - An example of this preparation can be found in git commit fc548b991fb0.
> > > + An older example of this preparation can be found in git commit
> > > + fc548b991fb0, although this was splitting into three parts; the
> > > + link-up part now includes configuring the MAC for the link settings.
> > > + Please see :c:func:`mac_link_up` for more information on this.
> > >
> > > 2. Replace::
> > >
> > > @@ -207,6 +210,14 @@ this documentation.
> > > using. This is particularly important for in-band negotiation
> > > methods such as 1000base-X and SGMII.
> > >
> > > + The :c:func:`mac_link_up` method is used to inform the MAC that the
> > > + link has come up. The call includes the negotiation mode and interface
> > > + for reference only. The finalised link parameters are also supplied
> > > + (speed, duplex and flow control/pause enablement settings) which
> > > + should be used to configure the MAC when the MAC and PCS are not
> > > + tightly integrated, or when the settings are not coming from in-band
> > > + negotiation.
> > > +
> > > The :c:func:`mac_config` method is used to update the MAC with the
> > > requested state, and must avoid unnecessarily taking the link down
> > > when making changes to the MAC configuration. This means the
> >
> > Just to make sure I understand the changes:
> > - A MAC with no PCS can be configured in either .mac_config or .mac_link_up
>
> I would much prefer mac_link_up to be used for setting the speed,
> duplex and pause modes for future-proofing in all cases except for
> the case where these parameters are automatically updated in the
> MAC from its associated PCS.
>
> mac_link_up must not be used to configure the AN mode or interface
> mode; these must be configured in mac_config().
>
> > - A MAC that needs to be manually reconfigured to the link mode
> > negotiated by its PCS needs to have the PCS configured in .mac_config
> > and the MAC in .mac_link_up
>
> I do have further changes that split the PCS ops from the MAC ops, so
> what is in this series is not the full story yet - some of the further
> patches can be found in my "phy" branch and "cex7" branches where I add
> support to dpaa2 for automatically switching between SGMII and
> 1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the
> extra complication that there's a firmware layer between the PCS and
> MAC.
>
> However, this series is the first stand-alone step along the road to
> supporting split PCS/MAC setups in a sane manner.
>
> I discussed with Andrew Lunn how much to send, and the conclusion was
> to make the changes in a number of small patch series, as large patch
> series tend not to get reviewed. My experience with _this_ series is
> that even this is very difficult to get feedback for, so adding any
> additional patches will just make that worse.
>
> > - A MAC with PCS where the MAC follows the PCS negotiation
> > automatically in hardware is basically equivalent with a MAC with no
> > PCS, and therefore can be configured in either .mac_config or
> > .mac_link_up
>
> In this case, mac_link_up doesn't do anything with the speed/duplex/
> pause stuff when those are automatically passed from the PCS.
>
> I'm afraid that sentence contains a subtlety that's going to get
> people: it is not clear cut because of the different natures of the
> various links.
>
> In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the
> duplex and pause with the remote end. For mvneta (an example of a
> combined PCS/MAC implementation) operating in-band:
> - In mac_config():
> - configures for 1000BASE-X interface type with in-band AN.
> - configures fixed 1G.
> - As mvneta only supports full duplex, we disable duplex negotiation
> and force full duplex.
> - Only symmetric pause is supported, and we set the symmetric pause
> advertisement appropriately, with pause negotiation enabled.
> - In mac_link_up():
> - merely allow the device to transmit and receive.
>
> The MAC will be forced to 1G, full duplex, and will automatically be
> configured by the PCS for pause support depending on the hardware
> based pause resolution.
>
> The situation is different for SGMII operating in-band:
> - In mac_config():
> - configures for SGMII interface type with in-band AN.
> - configures speed and duplex negotiation.
> - disables pause negotiation; SGMII has no support for this.
> - In mac_link_up():
> - enables or disables pause frames depending on the tx_pause/
> rx_pause flags, since this is not available from the MAC.
> - allow the device to transmit and receive.
>
> If we aren't operating in in-band mode, then:
> - In mac_config():
> - configures for the interface type without in-band AN.
> - disables speed, duplex and pause negotiation.
> - In mac_link_up():
> - sets the speed, duplex and pause frames depending on the passed
> parameters.
But there shouldn't be any requirement for this to be configured at
this step and not earlier?
> - allow the device to transmit and receive.
>
> Please see patch 7 of this series which implements this for mvneta.
>
> So, there is a split between what mac_config() should be doing and what
> mac_link_up() should be doing; this is why I've said in the
> documentation that the "mode" and "interface" are for reference only in
> mac_link_up() - mac_link_up() can use these to decide _how_ to program
> the resolved parameters, but should _not_ use them to determine the
> link configuration (such as changing the interface between SGMII and
> 1000BASE-X - that is the responsibility of mac_config().)
Does any driver currently make any use of the phy_interface_t argument
provided as reference in .mac_link_up?
>
> I hope that helps clarify the situation.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
Ok, so basically what is known early, as well as whatever is needed
for the in-band AN preparation, is configured in .mac_config and what
is known late is configured in .mac_link_up.
Except that you would like to slowly move everything MAC-related to
.mac_link_up, and everything PCS-related to .mac_config, presumably in
an effort to convert .mac_config to .pcs_config and .mac_link_up to
.mac_config. I don't actually know what other patches you have in the
cex7 branch you mentioned. Please consider that people don't
necessarily bookmark your git trees. I've spent some good 10 minutes
searching for the "cex7" and "phy" keywords in emails received from
you, and haven't found the git links.
Regards,
-Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
2020-02-26 13:00 ` Vladimir Oltean
(?)
@ 2020-02-26 13:36 ` Russell King - ARM Linux admin
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 13:36 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Heiner Kallweit, David S. Miller, Felix Fietkau
On Wed, Feb 26, 2020 at 03:00:30PM +0200, Vladimir Oltean wrote:
> On Wed, 26 Feb 2020 at 13:56, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote:
> > > Hi Russell,
> > >
> > > On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > > >
> > > > Propagate the resolved link parameters via the mac_link_up() call for
> > > > MACs that do not automatically track their PCS state. We propagate the
> > > > link parameters via function arguments so that inappropriate members
> > > > of struct phylink_link_state can't be accessed, and creating a new
> > > > structure just for this adds needless complexity to the API.
> > > >
> > > > Tested-by: Andre Przywara <andre.przywara@arm.com>
> > > > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > > > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > > ---
> > > > Documentation/networking/sfp-phylink.rst | 17 +++++-
> > > > drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> > > > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> > > > drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> > > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> > > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> > > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> > > > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> > > > drivers/net/phy/phylink.c | 9 ++-
> > > > include/linux/phylink.h | 57 ++++++++++++++-----
> > > > net/dsa/port.c | 4 +-
> > > > 11 files changed, 105 insertions(+), 41 deletions(-)
> > > >
> > > > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> > > > index d753a309f9d1..8d7af28cd835 100644
> > > > --- a/Documentation/networking/sfp-phylink.rst
> > > > +++ b/Documentation/networking/sfp-phylink.rst
> > > > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> > > > this documentation.
> > > >
> > > > 1. Optionally split the network driver's phylib update function into
> > > > - three parts dealing with link-down, link-up and reconfiguring the
> > > > - MAC settings. This can be done as a separate preparation commit.
> > > > + two parts dealing with link-down and link-up. This can be done as
> > > > + a separate preparation commit.
> > > >
> > > > - An example of this preparation can be found in git commit fc548b991fb0.
> > > > + An older example of this preparation can be found in git commit
> > > > + fc548b991fb0, although this was splitting into three parts; the
> > > > + link-up part now includes configuring the MAC for the link settings.
> > > > + Please see :c:func:`mac_link_up` for more information on this.
> > > >
> > > > 2. Replace::
> > > >
> > > > @@ -207,6 +210,14 @@ this documentation.
> > > > using. This is particularly important for in-band negotiation
> > > > methods such as 1000base-X and SGMII.
> > > >
> > > > + The :c:func:`mac_link_up` method is used to inform the MAC that the
> > > > + link has come up. The call includes the negotiation mode and interface
> > > > + for reference only. The finalised link parameters are also supplied
> > > > + (speed, duplex and flow control/pause enablement settings) which
> > > > + should be used to configure the MAC when the MAC and PCS are not
> > > > + tightly integrated, or when the settings are not coming from in-band
> > > > + negotiation.
> > > > +
> > > > The :c:func:`mac_config` method is used to update the MAC with the
> > > > requested state, and must avoid unnecessarily taking the link down
> > > > when making changes to the MAC configuration. This means the
> > >
> > > Just to make sure I understand the changes:
> > > - A MAC with no PCS can be configured in either .mac_config or .mac_link_up
> >
> > I would much prefer mac_link_up to be used for setting the speed,
> > duplex and pause modes for future-proofing in all cases except for
> > the case where these parameters are automatically updated in the
> > MAC from its associated PCS.
> >
> > mac_link_up must not be used to configure the AN mode or interface
> > mode; these must be configured in mac_config().
> >
> > > - A MAC that needs to be manually reconfigured to the link mode
> > > negotiated by its PCS needs to have the PCS configured in .mac_config
> > > and the MAC in .mac_link_up
> >
> > I do have further changes that split the PCS ops from the MAC ops, so
> > what is in this series is not the full story yet - some of the further
> > patches can be found in my "phy" branch and "cex7" branches where I add
> > support to dpaa2 for automatically switching between SGMII and
> > 1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the
> > extra complication that there's a firmware layer between the PCS and
> > MAC.
> >
> > However, this series is the first stand-alone step along the road to
> > supporting split PCS/MAC setups in a sane manner.
> >
> > I discussed with Andrew Lunn how much to send, and the conclusion was
> > to make the changes in a number of small patch series, as large patch
> > series tend not to get reviewed. My experience with _this_ series is
> > that even this is very difficult to get feedback for, so adding any
> > additional patches will just make that worse.
> >
> > > - A MAC with PCS where the MAC follows the PCS negotiation
> > > automatically in hardware is basically equivalent with a MAC with no
> > > PCS, and therefore can be configured in either .mac_config or
> > > .mac_link_up
> >
> > In this case, mac_link_up doesn't do anything with the speed/duplex/
> > pause stuff when those are automatically passed from the PCS.
> >
> > I'm afraid that sentence contains a subtlety that's going to get
> > people: it is not clear cut because of the different natures of the
> > various links.
> >
> > In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the
> > duplex and pause with the remote end. For mvneta (an example of a
> > combined PCS/MAC implementation) operating in-band:
> > - In mac_config():
> > - configures for 1000BASE-X interface type with in-band AN.
> > - configures fixed 1G.
> > - As mvneta only supports full duplex, we disable duplex negotiation
> > and force full duplex.
> > - Only symmetric pause is supported, and we set the symmetric pause
> > advertisement appropriately, with pause negotiation enabled.
> > - In mac_link_up():
> > - merely allow the device to transmit and receive.
> >
> > The MAC will be forced to 1G, full duplex, and will automatically be
> > configured by the PCS for pause support depending on the hardware
> > based pause resolution.
> >
> > The situation is different for SGMII operating in-band:
> > - In mac_config():
> > - configures for SGMII interface type with in-band AN.
> > - configures speed and duplex negotiation.
> > - disables pause negotiation; SGMII has no support for this.
> > - In mac_link_up():
> > - enables or disables pause frames depending on the tx_pause/
> > rx_pause flags, since this is not available from the MAC.
> > - allow the device to transmit and receive.
> >
> > If we aren't operating in in-band mode, then:
> > - In mac_config():
> > - configures for the interface type without in-band AN.
> > - disables speed, duplex and pause negotiation.
> > - In mac_link_up():
> > - sets the speed, duplex and pause frames depending on the passed
> > parameters.
>
> But there shouldn't be any requirement for this to be configured at
> this step and not earlier?
>
> > - allow the device to transmit and receive.
> >
> > Please see patch 7 of this series which implements this for mvneta.
> >
> > So, there is a split between what mac_config() should be doing and what
> > mac_link_up() should be doing; this is why I've said in the
> > documentation that the "mode" and "interface" are for reference only in
> > mac_link_up() - mac_link_up() can use these to decide _how_ to program
> > the resolved parameters, but should _not_ use them to determine the
> > link configuration (such as changing the interface between SGMII and
> > 1000BASE-X - that is the responsibility of mac_config().)
>
> Does any driver currently make any use of the phy_interface_t argument
> provided as reference in .mac_link_up?
Yes. mvpp2 uses it to decide whether to configure the 10/100/1G MAC
or the 10G XLG MAC, for example - there are drivers that need to
configure different blocks for the link-up event depending on the
interface mode. Rather than having drivers store the interface mode
internally, copying what phylink is doing, we provide that to the
network driver so it can make its own decisions without that additional
complexity.
> > I hope that helps clarify the situation.
> >
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> > According to speedtest.net: 11.9Mbps down 500kbps up
>
> Ok, so basically what is known early, as well as whatever is needed
> for the in-band AN preparation, is configured in .mac_config and what
> is known late is configured in .mac_link_up.
I envision a time when the speed/duplex/pause settings will not be
passed to mac_config.
> Except that you would like to slowly move everything MAC-related to
> .mac_link_up, and everything PCS-related to .mac_config, presumably in
> an effort to convert .mac_config to .pcs_config and .mac_link_up to
> .mac_config. I don't actually know what other patches you have in the
> cex7 branch you mentioned. Please consider that people don't
> necessarily bookmark your git trees. I've spent some good 10 minutes
> searching for the "cex7" and "phy" keywords in emails received from
> you, and haven't found the git links.
http://git.armlinux.org.uk/cgit/linux-arm.git/
I'm afraid that it's rather scattered amongst quite a few branches at
the moment, because of their dependencies on other stuff in my tree.
For dpaa2, see:
http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=cex7
specifically:
"dpaa2-mac: add PCS support"
"net: phylink: add c45 pcs helpers"
"net: phylink: helpers for 802.3 clause 37/SGMII register sets"
"net: phylink: add pcs operations"
"net: phylink: rename 'ops' to 'mac_ops'"
"net: mii: add linkmode_adv_to_mii_adv_x()"
"net: mii: convert mii_lpa_to_ethtool_lpa_x() to linkmode variant"
dpaa2 is complicated by the firmware, and that we can't switch the
interface mode between (SGMII,1000base-X) and 10G.
If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
the current link parameters via the dpmac_set_link_state() call - it
isn't clear whether that needs to be called for other modes with the
up/down state (firmware API documentation is poor.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 13:36 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 13:36 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
On Wed, Feb 26, 2020 at 03:00:30PM +0200, Vladimir Oltean wrote:
> On Wed, 26 Feb 2020 at 13:56, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote:
> > > Hi Russell,
> > >
> > > On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > > >
> > > > Propagate the resolved link parameters via the mac_link_up() call for
> > > > MACs that do not automatically track their PCS state. We propagate the
> > > > link parameters via function arguments so that inappropriate members
> > > > of struct phylink_link_state can't be accessed, and creating a new
> > > > structure just for this adds needless complexity to the API.
> > > >
> > > > Tested-by: Andre Przywara <andre.przywara@arm.com>
> > > > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > > > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > > ---
> > > > Documentation/networking/sfp-phylink.rst | 17 +++++-
> > > > drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> > > > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> > > > drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> > > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> > > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> > > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> > > > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> > > > drivers/net/phy/phylink.c | 9 ++-
> > > > include/linux/phylink.h | 57 ++++++++++++++-----
> > > > net/dsa/port.c | 4 +-
> > > > 11 files changed, 105 insertions(+), 41 deletions(-)
> > > >
> > > > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> > > > index d753a309f9d1..8d7af28cd835 100644
> > > > --- a/Documentation/networking/sfp-phylink.rst
> > > > +++ b/Documentation/networking/sfp-phylink.rst
> > > > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> > > > this documentation.
> > > >
> > > > 1. Optionally split the network driver's phylib update function into
> > > > - three parts dealing with link-down, link-up and reconfiguring the
> > > > - MAC settings. This can be done as a separate preparation commit.
> > > > + two parts dealing with link-down and link-up. This can be done as
> > > > + a separate preparation commit.
> > > >
> > > > - An example of this preparation can be found in git commit fc548b991fb0.
> > > > + An older example of this preparation can be found in git commit
> > > > + fc548b991fb0, although this was splitting into three parts; the
> > > > + link-up part now includes configuring the MAC for the link settings.
> > > > + Please see :c:func:`mac_link_up` for more information on this.
> > > >
> > > > 2. Replace::
> > > >
> > > > @@ -207,6 +210,14 @@ this documentation.
> > > > using. This is particularly important for in-band negotiation
> > > > methods such as 1000base-X and SGMII.
> > > >
> > > > + The :c:func:`mac_link_up` method is used to inform the MAC that the
> > > > + link has come up. The call includes the negotiation mode and interface
> > > > + for reference only. The finalised link parameters are also supplied
> > > > + (speed, duplex and flow control/pause enablement settings) which
> > > > + should be used to configure the MAC when the MAC and PCS are not
> > > > + tightly integrated, or when the settings are not coming from in-band
> > > > + negotiation.
> > > > +
> > > > The :c:func:`mac_config` method is used to update the MAC with the
> > > > requested state, and must avoid unnecessarily taking the link down
> > > > when making changes to the MAC configuration. This means the
> > >
> > > Just to make sure I understand the changes:
> > > - A MAC with no PCS can be configured in either .mac_config or .mac_link_up
> >
> > I would much prefer mac_link_up to be used for setting the speed,
> > duplex and pause modes for future-proofing in all cases except for
> > the case where these parameters are automatically updated in the
> > MAC from its associated PCS.
> >
> > mac_link_up must not be used to configure the AN mode or interface
> > mode; these must be configured in mac_config().
> >
> > > - A MAC that needs to be manually reconfigured to the link mode
> > > negotiated by its PCS needs to have the PCS configured in .mac_config
> > > and the MAC in .mac_link_up
> >
> > I do have further changes that split the PCS ops from the MAC ops, so
> > what is in this series is not the full story yet - some of the further
> > patches can be found in my "phy" branch and "cex7" branches where I add
> > support to dpaa2 for automatically switching between SGMII and
> > 1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the
> > extra complication that there's a firmware layer between the PCS and
> > MAC.
> >
> > However, this series is the first stand-alone step along the road to
> > supporting split PCS/MAC setups in a sane manner.
> >
> > I discussed with Andrew Lunn how much to send, and the conclusion was
> > to make the changes in a number of small patch series, as large patch
> > series tend not to get reviewed. My experience with _this_ series is
> > that even this is very difficult to get feedback for, so adding any
> > additional patches will just make that worse.
> >
> > > - A MAC with PCS where the MAC follows the PCS negotiation
> > > automatically in hardware is basically equivalent with a MAC with no
> > > PCS, and therefore can be configured in either .mac_config or
> > > .mac_link_up
> >
> > In this case, mac_link_up doesn't do anything with the speed/duplex/
> > pause stuff when those are automatically passed from the PCS.
> >
> > I'm afraid that sentence contains a subtlety that's going to get
> > people: it is not clear cut because of the different natures of the
> > various links.
> >
> > In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the
> > duplex and pause with the remote end. For mvneta (an example of a
> > combined PCS/MAC implementation) operating in-band:
> > - In mac_config():
> > - configures for 1000BASE-X interface type with in-band AN.
> > - configures fixed 1G.
> > - As mvneta only supports full duplex, we disable duplex negotiation
> > and force full duplex.
> > - Only symmetric pause is supported, and we set the symmetric pause
> > advertisement appropriately, with pause negotiation enabled.
> > - In mac_link_up():
> > - merely allow the device to transmit and receive.
> >
> > The MAC will be forced to 1G, full duplex, and will automatically be
> > configured by the PCS for pause support depending on the hardware
> > based pause resolution.
> >
> > The situation is different for SGMII operating in-band:
> > - In mac_config():
> > - configures for SGMII interface type with in-band AN.
> > - configures speed and duplex negotiation.
> > - disables pause negotiation; SGMII has no support for this.
> > - In mac_link_up():
> > - enables or disables pause frames depending on the tx_pause/
> > rx_pause flags, since this is not available from the MAC.
> > - allow the device to transmit and receive.
> >
> > If we aren't operating in in-band mode, then:
> > - In mac_config():
> > - configures for the interface type without in-band AN.
> > - disables speed, duplex and pause negotiation.
> > - In mac_link_up():
> > - sets the speed, duplex and pause frames depending on the passed
> > parameters.
>
> But there shouldn't be any requirement for this to be configured at
> this step and not earlier?
>
> > - allow the device to transmit and receive.
> >
> > Please see patch 7 of this series which implements this for mvneta.
> >
> > So, there is a split between what mac_config() should be doing and what
> > mac_link_up() should be doing; this is why I've said in the
> > documentation that the "mode" and "interface" are for reference only in
> > mac_link_up() - mac_link_up() can use these to decide _how_ to program
> > the resolved parameters, but should _not_ use them to determine the
> > link configuration (such as changing the interface between SGMII and
> > 1000BASE-X - that is the responsibility of mac_config().)
>
> Does any driver currently make any use of the phy_interface_t argument
> provided as reference in .mac_link_up?
Yes. mvpp2 uses it to decide whether to configure the 10/100/1G MAC
or the 10G XLG MAC, for example - there are drivers that need to
configure different blocks for the link-up event depending on the
interface mode. Rather than having drivers store the interface mode
internally, copying what phylink is doing, we provide that to the
network driver so it can make its own decisions without that additional
complexity.
> > I hope that helps clarify the situation.
> >
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> > According to speedtest.net: 11.9Mbps down 500kbps up
>
> Ok, so basically what is known early, as well as whatever is needed
> for the in-band AN preparation, is configured in .mac_config and what
> is known late is configured in .mac_link_up.
I envision a time when the speed/duplex/pause settings will not be
passed to mac_config.
> Except that you would like to slowly move everything MAC-related to
> .mac_link_up, and everything PCS-related to .mac_config, presumably in
> an effort to convert .mac_config to .pcs_config and .mac_link_up to
> .mac_config. I don't actually know what other patches you have in the
> cex7 branch you mentioned. Please consider that people don't
> necessarily bookmark your git trees. I've spent some good 10 minutes
> searching for the "cex7" and "phy" keywords in emails received from
> you, and haven't found the git links.
http://git.armlinux.org.uk/cgit/linux-arm.git/
I'm afraid that it's rather scattered amongst quite a few branches at
the moment, because of their dependencies on other stuff in my tree.
For dpaa2, see:
http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=cex7
specifically:
"dpaa2-mac: add PCS support"
"net: phylink: add c45 pcs helpers"
"net: phylink: helpers for 802.3 clause 37/SGMII register sets"
"net: phylink: add pcs operations"
"net: phylink: rename 'ops' to 'mac_ops'"
"net: mii: add linkmode_adv_to_mii_adv_x()"
"net: mii: convert mii_lpa_to_ethtool_lpa_x() to linkmode variant"
dpaa2 is complicated by the firmware, and that we can't switch the
interface mode between (SGMII,1000base-X) and 10G.
If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
the current link parameters via the dpmac_set_link_state() call - it
isn't clear whether that needs to be called for other modes with the
up/down state (firmware API documentation is poor.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 13:36 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 13:36 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
On Wed, Feb 26, 2020 at 03:00:30PM +0200, Vladimir Oltean wrote:
> On Wed, 26 Feb 2020 at 13:56, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote:
> > > Hi Russell,
> > >
> > > On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > > >
> > > > Propagate the resolved link parameters via the mac_link_up() call for
> > > > MACs that do not automatically track their PCS state. We propagate the
> > > > link parameters via function arguments so that inappropriate members
> > > > of struct phylink_link_state can't be accessed, and creating a new
> > > > structure just for this adds needless complexity to the API.
> > > >
> > > > Tested-by: Andre Przywara <andre.przywara@arm.com>
> > > > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > > > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > > ---
> > > > Documentation/networking/sfp-phylink.rst | 17 +++++-
> > > > drivers/net/ethernet/cadence/macb_main.c | 7 ++-
> > > > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++-
> > > > drivers/net/ethernet/marvell/mvneta.c | 8 ++-
> > > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++--
> > > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-
> > > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
> > > > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++-
> > > > drivers/net/phy/phylink.c | 9 ++-
> > > > include/linux/phylink.h | 57 ++++++++++++++-----
> > > > net/dsa/port.c | 4 +-
> > > > 11 files changed, 105 insertions(+), 41 deletions(-)
> > > >
> > > > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst
> > > > index d753a309f9d1..8d7af28cd835 100644
> > > > --- a/Documentation/networking/sfp-phylink.rst
> > > > +++ b/Documentation/networking/sfp-phylink.rst
> > > > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve
> > > > this documentation.
> > > >
> > > > 1. Optionally split the network driver's phylib update function into
> > > > - three parts dealing with link-down, link-up and reconfiguring the
> > > > - MAC settings. This can be done as a separate preparation commit.
> > > > + two parts dealing with link-down and link-up. This can be done as
> > > > + a separate preparation commit.
> > > >
> > > > - An example of this preparation can be found in git commit fc548b991fb0.
> > > > + An older example of this preparation can be found in git commit
> > > > + fc548b991fb0, although this was splitting into three parts; the
> > > > + link-up part now includes configuring the MAC for the link settings.
> > > > + Please see :c:func:`mac_link_up` for more information on this.
> > > >
> > > > 2. Replace::
> > > >
> > > > @@ -207,6 +210,14 @@ this documentation.
> > > > using. This is particularly important for in-band negotiation
> > > > methods such as 1000base-X and SGMII.
> > > >
> > > > + The :c:func:`mac_link_up` method is used to inform the MAC that the
> > > > + link has come up. The call includes the negotiation mode and interface
> > > > + for reference only. The finalised link parameters are also supplied
> > > > + (speed, duplex and flow control/pause enablement settings) which
> > > > + should be used to configure the MAC when the MAC and PCS are not
> > > > + tightly integrated, or when the settings are not coming from in-band
> > > > + negotiation.
> > > > +
> > > > The :c:func:`mac_config` method is used to update the MAC with the
> > > > requested state, and must avoid unnecessarily taking the link down
> > > > when making changes to the MAC configuration. This means the
> > >
> > > Just to make sure I understand the changes:
> > > - A MAC with no PCS can be configured in either .mac_config or .mac_link_up
> >
> > I would much prefer mac_link_up to be used for setting the speed,
> > duplex and pause modes for future-proofing in all cases except for
> > the case where these parameters are automatically updated in the
> > MAC from its associated PCS.
> >
> > mac_link_up must not be used to configure the AN mode or interface
> > mode; these must be configured in mac_config().
> >
> > > - A MAC that needs to be manually reconfigured to the link mode
> > > negotiated by its PCS needs to have the PCS configured in .mac_config
> > > and the MAC in .mac_link_up
> >
> > I do have further changes that split the PCS ops from the MAC ops, so
> > what is in this series is not the full story yet - some of the further
> > patches can be found in my "phy" branch and "cex7" branches where I add
> > support to dpaa2 for automatically switching between SGMII and
> > 1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the
> > extra complication that there's a firmware layer between the PCS and
> > MAC.
> >
> > However, this series is the first stand-alone step along the road to
> > supporting split PCS/MAC setups in a sane manner.
> >
> > I discussed with Andrew Lunn how much to send, and the conclusion was
> > to make the changes in a number of small patch series, as large patch
> > series tend not to get reviewed. My experience with _this_ series is
> > that even this is very difficult to get feedback for, so adding any
> > additional patches will just make that worse.
> >
> > > - A MAC with PCS where the MAC follows the PCS negotiation
> > > automatically in hardware is basically equivalent with a MAC with no
> > > PCS, and therefore can be configured in either .mac_config or
> > > .mac_link_up
> >
> > In this case, mac_link_up doesn't do anything with the speed/duplex/
> > pause stuff when those are automatically passed from the PCS.
> >
> > I'm afraid that sentence contains a subtlety that's going to get
> > people: it is not clear cut because of the different natures of the
> > various links.
> >
> > In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the
> > duplex and pause with the remote end. For mvneta (an example of a
> > combined PCS/MAC implementation) operating in-band:
> > - In mac_config():
> > - configures for 1000BASE-X interface type with in-band AN.
> > - configures fixed 1G.
> > - As mvneta only supports full duplex, we disable duplex negotiation
> > and force full duplex.
> > - Only symmetric pause is supported, and we set the symmetric pause
> > advertisement appropriately, with pause negotiation enabled.
> > - In mac_link_up():
> > - merely allow the device to transmit and receive.
> >
> > The MAC will be forced to 1G, full duplex, and will automatically be
> > configured by the PCS for pause support depending on the hardware
> > based pause resolution.
> >
> > The situation is different for SGMII operating in-band:
> > - In mac_config():
> > - configures for SGMII interface type with in-band AN.
> > - configures speed and duplex negotiation.
> > - disables pause negotiation; SGMII has no support for this.
> > - In mac_link_up():
> > - enables or disables pause frames depending on the tx_pause/
> > rx_pause flags, since this is not available from the MAC.
> > - allow the device to transmit and receive.
> >
> > If we aren't operating in in-band mode, then:
> > - In mac_config():
> > - configures for the interface type without in-band AN.
> > - disables speed, duplex and pause negotiation.
> > - In mac_link_up():
> > - sets the speed, duplex and pause frames depending on the passed
> > parameters.
>
> But there shouldn't be any requirement for this to be configured at
> this step and not earlier?
>
> > - allow the device to transmit and receive.
> >
> > Please see patch 7 of this series which implements this for mvneta.
> >
> > So, there is a split between what mac_config() should be doing and what
> > mac_link_up() should be doing; this is why I've said in the
> > documentation that the "mode" and "interface" are for reference only in
> > mac_link_up() - mac_link_up() can use these to decide _how_ to program
> > the resolved parameters, but should _not_ use them to determine the
> > link configuration (such as changing the interface between SGMII and
> > 1000BASE-X - that is the responsibility of mac_config().)
>
> Does any driver currently make any use of the phy_interface_t argument
> provided as reference in .mac_link_up?
Yes. mvpp2 uses it to decide whether to configure the 10/100/1G MAC
or the 10G XLG MAC, for example - there are drivers that need to
configure different blocks for the link-up event depending on the
interface mode. Rather than having drivers store the interface mode
internally, copying what phylink is doing, we provide that to the
network driver so it can make its own decisions without that additional
complexity.
> > I hope that helps clarify the situation.
> >
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> > According to speedtest.net: 11.9Mbps down 500kbps up
>
> Ok, so basically what is known early, as well as whatever is needed
> for the in-band AN preparation, is configured in .mac_config and what
> is known late is configured in .mac_link_up.
I envision a time when the speed/duplex/pause settings will not be
passed to mac_config.
> Except that you would like to slowly move everything MAC-related to
> .mac_link_up, and everything PCS-related to .mac_config, presumably in
> an effort to convert .mac_config to .pcs_config and .mac_link_up to
> .mac_config. I don't actually know what other patches you have in the
> cex7 branch you mentioned. Please consider that people don't
> necessarily bookmark your git trees. I've spent some good 10 minutes
> searching for the "cex7" and "phy" keywords in emails received from
> you, and haven't found the git links.
http://git.armlinux.org.uk/cgit/linux-arm.git/
I'm afraid that it's rather scattered amongst quite a few branches at
the moment, because of their dependencies on other stuff in my tree.
For dpaa2, see:
http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=cex7
specifically:
"dpaa2-mac: add PCS support"
"net: phylink: add c45 pcs helpers"
"net: phylink: helpers for 802.3 clause 37/SGMII register sets"
"net: phylink: add pcs operations"
"net: phylink: rename 'ops' to 'mac_ops'"
"net: mii: add linkmode_adv_to_mii_adv_x()"
"net: mii: convert mii_lpa_to_ethtool_lpa_x() to linkmode variant"
dpaa2 is complicated by the firmware, and that we can't switch the
interface mode between (SGMII,1000base-X) and 10G.
If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
the current link parameters via the dpmac_set_link_state() call - it
isn't clear whether that needs to be called for other modes with the
up/down state (firmware API documentation is poor.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
2020-02-26 13:36 ` Russell King - ARM Linux admin
(?)
@ 2020-02-26 18:21 ` Vladimir Oltean
-1 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 18:21 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Heiner Kallweit, David S. Miller, Felix Fietkau
On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
>
> dpaa2 is complicated by the firmware, and that we can't switch the
> interface mode between (SGMII,1000base-X) and 10G.
>
> If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
> the current link parameters via the dpmac_set_link_state() call - it
> isn't clear whether that needs to be called for other modes with the
> up/down state (firmware API documentation is poor.)
>
With PCS control in Linux, I am pretty sure that you don't want
anything other than DPMAC_LINK_TYPE_PHY anyway.
Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
the PCS and polls its link state to emit link notifications to objects
connected to the DPMAC. So Linux control of PCS would class with
firmware control of the PCS, leading to undesirable side-effects to
say the least.
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
Regards,
-Vladimir
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 18:21 ` Vladimir Oltean
0 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 18:21 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
>
> dpaa2 is complicated by the firmware, and that we can't switch the
> interface mode between (SGMII,1000base-X) and 10G.
>
> If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
> the current link parameters via the dpmac_set_link_state() call - it
> isn't clear whether that needs to be called for other modes with the
> up/down state (firmware API documentation is poor.)
>
With PCS control in Linux, I am pretty sure that you don't want
anything other than DPMAC_LINK_TYPE_PHY anyway.
Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
the PCS and polls its link state to emit link notifications to objects
connected to the DPMAC. So Linux control of PCS would class with
firmware control of the PCS, leading to undesirable side-effects to
say the least.
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
Regards,
-Vladimir
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 18:21 ` Vladimir Oltean
0 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 18:21 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
>
> dpaa2 is complicated by the firmware, and that we can't switch the
> interface mode between (SGMII,1000base-X) and 10G.
>
> If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
> the current link parameters via the dpmac_set_link_state() call - it
> isn't clear whether that needs to be called for other modes with the
> up/down state (firmware API documentation is poor.)
>
With PCS control in Linux, I am pretty sure that you don't want
anything other than DPMAC_LINK_TYPE_PHY anyway.
Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
the PCS and polls its link state to emit link notifications to objects
connected to the DPMAC. So Linux control of PCS would class with
firmware control of the PCS, leading to undesirable side-effects to
say the least.
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
Regards,
-Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
2020-02-26 18:21 ` Vladimir Oltean
(?)
@ 2020-02-26 18:22 ` Vladimir Oltean
-1 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 18:22 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Heiner Kallweit, David S. Miller, Felix Fietkau
On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
>
> On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> >
> > dpaa2 is complicated by the firmware, and that we can't switch the
> > interface mode between (SGMII,1000base-X) and 10G.
> >
> > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
> > the current link parameters via the dpmac_set_link_state() call - it
> > isn't clear whether that needs to be called for other modes with the
> > up/down state (firmware API documentation is poor.)
> >
>
> With PCS control in Linux, I am pretty sure that you don't want
> anything other than DPMAC_LINK_TYPE_PHY anyway.
> Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> the PCS and polls its link state to emit link notifications to objects
> connected to the DPMAC. So Linux control of PCS would class with
s/class/clash/
> firmware control of the PCS, leading to undesirable side-effects to
> say the least.
>
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> > According to speedtest.net: 11.9Mbps down 500kbps up
>
> Regards,
> -Vladimir
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 18:22 ` Vladimir Oltean
0 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 18:22 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
>
> On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> >
> > dpaa2 is complicated by the firmware, and that we can't switch the
> > interface mode between (SGMII,1000base-X) and 10G.
> >
> > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
> > the current link parameters via the dpmac_set_link_state() call - it
> > isn't clear whether that needs to be called for other modes with the
> > up/down state (firmware API documentation is poor.)
> >
>
> With PCS control in Linux, I am pretty sure that you don't want
> anything other than DPMAC_LINK_TYPE_PHY anyway.
> Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> the PCS and polls its link state to emit link notifications to objects
> connected to the DPMAC. So Linux control of PCS would class with
s/class/clash/
> firmware control of the PCS, leading to undesirable side-effects to
> say the least.
>
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> > According to speedtest.net: 11.9Mbps down 500kbps up
>
> Regards,
> -Vladimir
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 18:22 ` Vladimir Oltean
0 siblings, 0 replies; 60+ messages in thread
From: Vladimir Oltean @ 2020-02-26 18:22 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
>
> On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> >
> > dpaa2 is complicated by the firmware, and that we can't switch the
> > interface mode between (SGMII,1000base-X) and 10G.
> >
> > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
> > the current link parameters via the dpmac_set_link_state() call - it
> > isn't clear whether that needs to be called for other modes with the
> > up/down state (firmware API documentation is poor.)
> >
>
> With PCS control in Linux, I am pretty sure that you don't want
> anything other than DPMAC_LINK_TYPE_PHY anyway.
> Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> the PCS and polls its link state to emit link notifications to objects
> connected to the DPMAC. So Linux control of PCS would class with
s/class/clash/
> firmware control of the PCS, leading to undesirable side-effects to
> say the least.
>
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> > According to speedtest.net: 11.9Mbps down 500kbps up
>
> Regards,
> -Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
2020-02-26 18:22 ` Vladimir Oltean
(?)
@ 2020-02-26 18:25 ` Russell King - ARM Linux admin
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 18:25 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
On Wed, Feb 26, 2020 at 08:22:39PM +0200, Vladimir Oltean wrote:
> On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > >
> > > dpaa2 is complicated by the firmware, and that we can't switch the
> > > interface mode between (SGMII,1000base-X) and 10G.
> > >
> > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
> > > the current link parameters via the dpmac_set_link_state() call - it
> > > isn't clear whether that needs to be called for other modes with the
> > > up/down state (firmware API documentation is poor.)
> > >
> >
> > With PCS control in Linux, I am pretty sure that you don't want
> > anything other than DPMAC_LINK_TYPE_PHY anyway.
> > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> > the PCS and polls its link state to emit link notifications to objects
> > connected to the DPMAC. So Linux control of PCS would class with
>
> s/class/clash/
>
> > firmware control of the PCS, leading to undesirable side-effects to
> > say the least.
Yes, which is why we only register the PCS with phylink if we're in
DPMAC_LINK_TYPE_PHY mode.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 18:25 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 18:25 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Heiner Kallweit, David S. Miller, Felix Fietkau
On Wed, Feb 26, 2020 at 08:22:39PM +0200, Vladimir Oltean wrote:
> On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > >
> > > dpaa2 is complicated by the firmware, and that we can't switch the
> > > interface mode between (SGMII,1000base-X) and 10G.
> > >
> > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
> > > the current link parameters via the dpmac_set_link_state() call - it
> > > isn't clear whether that needs to be called for other modes with the
> > > up/down state (firmware API documentation is poor.)
> > >
> >
> > With PCS control in Linux, I am pretty sure that you don't want
> > anything other than DPMAC_LINK_TYPE_PHY anyway.
> > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> > the PCS and polls its link state to emit link notifications to objects
> > connected to the DPMAC. So Linux control of PCS would class with
>
> s/class/clash/
>
> > firmware control of the PCS, leading to undesirable side-effects to
> > say the least.
Yes, which is why we only register the PCS with phylink if we're in
DPMAC_LINK_TYPE_PHY mode.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 18:25 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 18:25 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
Ioana Ciornei, linux-stm32, Florian Fainelli, Ioana Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Heiner Kallweit, David S. Miller, Felix Fietkau
On Wed, Feb 26, 2020 at 08:22:39PM +0200, Vladimir Oltean wrote:
> On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > >
> > > dpaa2 is complicated by the firmware, and that we can't switch the
> > > interface mode between (SGMII,1000base-X) and 10G.
> > >
> > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told
> > > the current link parameters via the dpmac_set_link_state() call - it
> > > isn't clear whether that needs to be called for other modes with the
> > > up/down state (firmware API documentation is poor.)
> > >
> >
> > With PCS control in Linux, I am pretty sure that you don't want
> > anything other than DPMAC_LINK_TYPE_PHY anyway.
> > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> > the PCS and polls its link state to emit link notifications to objects
> > connected to the DPMAC. So Linux control of PCS would class with
>
> s/class/clash/
>
> > firmware control of the PCS, leading to undesirable side-effects to
> > say the least.
Yes, which is why we only register the PCS with phylink if we're in
DPMAC_LINK_TYPE_PHY mode.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
* RE: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
2020-02-26 18:22 ` Vladimir Oltean
(?)
@ 2020-02-26 18:32 ` Ioana Ciornei
-1 siblings, 0 replies; 60+ messages in thread
From: Ioana Ciornei @ 2020-02-26 18:32 UTC (permalink / raw)
To: Vladimir Oltean, Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
linux-stm32, Florian Fainelli, Ioana Ciocoi Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Heiner Kallweit, David S. Miller, Felix Fietkau
> Subject: Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config
> via mac_link_up()
>
> On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > >
> > > dpaa2 is complicated by the firmware, and that we can't switch the
> > > interface mode between (SGMII,1000base-X) and 10G.
> > >
> > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be
> > > told the current link parameters via the dpmac_set_link_state() call
> > > - it isn't clear whether that needs to be called for other modes
> > > with the up/down state (firmware API documentation is poor.)
> > >
> >
> > With PCS control in Linux, I am pretty sure that you don't want
> > anything other than DPMAC_LINK_TYPE_PHY anyway.
> > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> > the PCS and polls its link state to emit link notifications to objects
> > connected to the DPMAC. So Linux control of PCS would class with
>
> s/class/clash/
>
> > firmware control of the PCS, leading to undesirable side-effects to
> > say the least.
If the DPMAC object is in DPMAC_LINK_TYPE_FIXED, the dpaa2-eth in fact
does not even connect to a phy so all the phylink interaction is not happening.
As Vladimir said, in this case it's the MC firmware's job to poll the PCS and
notify any connected objects of a link change.
> >
> > Regards,
> > -Vladimir
^ permalink raw reply [flat|nested] 60+ messages in thread
* RE: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 18:32 ` Ioana Ciornei
0 siblings, 0 replies; 60+ messages in thread
From: Ioana Ciornei @ 2020-02-26 18:32 UTC (permalink / raw)
To: Vladimir Oltean, Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
linux-stm32, Florian Fainelli, Ioana Ciocoi Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Vivien Didelot, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Mark Lee,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
> Subject: Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config
> via mac_link_up()
>
> On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > >
> > > dpaa2 is complicated by the firmware, and that we can't switch the
> > > interface mode between (SGMII,1000base-X) and 10G.
> > >
> > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be
> > > told the current link parameters via the dpmac_set_link_state() call
> > > - it isn't clear whether that needs to be called for other modes
> > > with the up/down state (firmware API documentation is poor.)
> > >
> >
> > With PCS control in Linux, I am pretty sure that you don't want
> > anything other than DPMAC_LINK_TYPE_PHY anyway.
> > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> > the PCS and polls its link state to emit link notifications to objects
> > connected to the DPMAC. So Linux control of PCS would class with
>
> s/class/clash/
>
> > firmware control of the PCS, leading to undesirable side-effects to
> > say the least.
If the DPMAC object is in DPMAC_LINK_TYPE_FIXED, the dpaa2-eth in fact
does not even connect to a phy so all the phylink interaction is not happening.
As Vladimir said, in this case it's the MC firmware's job to poll the PCS and
notify any connected objects of a link change.
> >
> > Regards,
> > -Vladimir
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* RE: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 18:32 ` Ioana Ciornei
0 siblings, 0 replies; 60+ messages in thread
From: Ioana Ciornei @ 2020-02-26 18:32 UTC (permalink / raw)
To: Vladimir Oltean, Russell King - ARM Linux admin
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
linux-stm32, Florian Fainelli, Ioana Ciocoi Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Vivien Didelot, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Mark Lee,
Maxime Coquelin, Felix Fietkau, David S. Miller, Heiner Kallweit
> Subject: Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config
> via mac_link_up()
>
> On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > >
> > > dpaa2 is complicated by the firmware, and that we can't switch the
> > > interface mode between (SGMII,1000base-X) and 10G.
> > >
> > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be
> > > told the current link parameters via the dpmac_set_link_state() call
> > > - it isn't clear whether that needs to be called for other modes
> > > with the up/down state (firmware API documentation is poor.)
> > >
> >
> > With PCS control in Linux, I am pretty sure that you don't want
> > anything other than DPMAC_LINK_TYPE_PHY anyway.
> > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> > the PCS and polls its link state to emit link notifications to objects
> > connected to the DPMAC. So Linux control of PCS would class with
>
> s/class/clash/
>
> > firmware control of the PCS, leading to undesirable side-effects to
> > say the least.
If the DPMAC object is in DPMAC_LINK_TYPE_FIXED, the dpaa2-eth in fact
does not even connect to a phy so all the phylink interaction is not happening.
As Vladimir said, in this case it's the MC firmware's job to poll the PCS and
notify any connected objects of a link change.
> >
> > Regards,
> > -Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
2020-02-26 18:32 ` Ioana Ciornei
(?)
@ 2020-02-26 19:11 ` Russell King - ARM Linux admin
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 19:11 UTC (permalink / raw)
To: Ioana Ciornei
Cc: Vladimir Oltean, Andrew Lunn, Linux Doc Mailing List,
Thomas Petazzoni, linux-stm32, Florian Fainelli,
Ioana Ciocoi Radulescu, Jonathan Corbet, Michal Simek,
Jose Abreu, Jakub Kicinski, Mark Lee, Sean Wang,
Alexandre Torgue, Hauke Mehrtens, Radhey Shyam Pandey,
moderated list:ARM/Mediatek SoC support, John Crispin,
Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Heiner Kallweit, David S. Miller, Felix Fietkau
On Wed, Feb 26, 2020 at 06:32:55PM +0000, Ioana Ciornei wrote:
> > Subject: Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config
> > via mac_link_up()
> >
> > On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
> > >
> > > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > >
> > > > dpaa2 is complicated by the firmware, and that we can't switch the
> > > > interface mode between (SGMII,1000base-X) and 10G.
> > > >
> > > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be
> > > > told the current link parameters via the dpmac_set_link_state() call
> > > > - it isn't clear whether that needs to be called for other modes
> > > > with the up/down state (firmware API documentation is poor.)
> > > >
> > >
> > > With PCS control in Linux, I am pretty sure that you don't want
> > > anything other than DPMAC_LINK_TYPE_PHY anyway.
> > > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> > > the PCS and polls its link state to emit link notifications to objects
> > > connected to the DPMAC. So Linux control of PCS would class with
> >
> > s/class/clash/
> >
> > > firmware control of the PCS, leading to undesirable side-effects to
> > > say the least.
>
>
> If the DPMAC object is in DPMAC_LINK_TYPE_FIXED, the dpaa2-eth in fact
> does not even connect to a phy so all the phylink interaction is not happening.
> As Vladimir said, in this case it's the MC firmware's job to poll the PCS and
> notify any connected objects of a link change.
Please see the patches I've referred Vladimir to, specifically this:
if (attr.link_type == DPMAC_LINK_TYPE_PHY) {
/* FIXME: how do we know whether this DPMAC has a PCS? */
err = dpaa2_pcs_create(mac, attr.id);
if (err)
goto err_phylink_destroy;
phylink_add_pcs(mac->phylink, &dpaa2_pcs_phylink_ops);
}
Hence, if we are not in DPMAC_LINK_TYPE_PHY, then we never talk to
the PCS, thereby satisfying the requirements of the firmware not to
touch the PCS if it's in FIXED mode.
It seems this is becoming a storm in a tea cup. Please stop.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 19:11 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 19:11 UTC (permalink / raw)
To: Ioana Ciornei
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
linux-stm32, Florian Fainelli, Ioana Ciocoi Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, Vladimir Oltean, David S. Miller,
Heiner Kallweit
On Wed, Feb 26, 2020 at 06:32:55PM +0000, Ioana Ciornei wrote:
> > Subject: Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config
> > via mac_link_up()
> >
> > On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
> > >
> > > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > >
> > > > dpaa2 is complicated by the firmware, and that we can't switch the
> > > > interface mode between (SGMII,1000base-X) and 10G.
> > > >
> > > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be
> > > > told the current link parameters via the dpmac_set_link_state() call
> > > > - it isn't clear whether that needs to be called for other modes
> > > > with the up/down state (firmware API documentation is poor.)
> > > >
> > >
> > > With PCS control in Linux, I am pretty sure that you don't want
> > > anything other than DPMAC_LINK_TYPE_PHY anyway.
> > > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> > > the PCS and polls its link state to emit link notifications to objects
> > > connected to the DPMAC. So Linux control of PCS would class with
> >
> > s/class/clash/
> >
> > > firmware control of the PCS, leading to undesirable side-effects to
> > > say the least.
>
>
> If the DPMAC object is in DPMAC_LINK_TYPE_FIXED, the dpaa2-eth in fact
> does not even connect to a phy so all the phylink interaction is not happening.
> As Vladimir said, in this case it's the MC firmware's job to poll the PCS and
> notify any connected objects of a link change.
Please see the patches I've referred Vladimir to, specifically this:
if (attr.link_type == DPMAC_LINK_TYPE_PHY) {
/* FIXME: how do we know whether this DPMAC has a PCS? */
err = dpaa2_pcs_create(mac, attr.id);
if (err)
goto err_phylink_destroy;
phylink_add_pcs(mac->phylink, &dpaa2_pcs_phylink_ops);
}
Hence, if we are not in DPMAC_LINK_TYPE_PHY, then we never talk to
the PCS, thereby satisfying the requirements of the firmware not to
touch the PCS if it's in FIXED mode.
It seems this is becoming a storm in a tea cup. Please stop.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up()
@ 2020-02-26 19:11 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-26 19:11 UTC (permalink / raw)
To: Ioana Ciornei
Cc: Andrew Lunn, Linux Doc Mailing List, Thomas Petazzoni,
linux-stm32, Florian Fainelli, Ioana Ciocoi Radulescu,
Jonathan Corbet, Michal Simek, Jose Abreu, Jakub Kicinski,
Mark Lee, Sean Wang, Alexandre Torgue, Hauke Mehrtens,
Radhey Shyam Pandey, moderated list:ARM/Mediatek SoC support,
John Crispin, Matthias Brugger, Giuseppe Cavallaro,
moderated list:ARM/Mediatek SoC support, netdev, Vivien Didelot,
Maxime Coquelin, Felix Fietkau, Vladimir Oltean, David S. Miller,
Heiner Kallweit
On Wed, Feb 26, 2020 at 06:32:55PM +0000, Ioana Ciornei wrote:
> > Subject: Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config
> > via mac_link_up()
> >
> > On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote:
> > >
> > > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > >
> > > > dpaa2 is complicated by the firmware, and that we can't switch the
> > > > interface mode between (SGMII,1000base-X) and 10G.
> > > >
> > > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be
> > > > told the current link parameters via the dpmac_set_link_state() call
> > > > - it isn't clear whether that needs to be called for other modes
> > > > with the up/down state (firmware API documentation is poor.)
> > > >
> > >
> > > With PCS control in Linux, I am pretty sure that you don't want
> > > anything other than DPMAC_LINK_TYPE_PHY anyway.
> > > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of
> > > the PCS and polls its link state to emit link notifications to objects
> > > connected to the DPMAC. So Linux control of PCS would class with
> >
> > s/class/clash/
> >
> > > firmware control of the PCS, leading to undesirable side-effects to
> > > say the least.
>
>
> If the DPMAC object is in DPMAC_LINK_TYPE_FIXED, the dpaa2-eth in fact
> does not even connect to a phy so all the phylink interaction is not happening.
> As Vladimir said, in this case it's the MC firmware's job to poll the PCS and
> notify any connected objects of a link change.
Please see the patches I've referred Vladimir to, specifically this:
if (attr.link_type == DPMAC_LINK_TYPE_PHY) {
/* FIXME: how do we know whether this DPMAC has a PCS? */
err = dpaa2_pcs_create(mac, attr.id);
if (err)
goto err_phylink_destroy;
phylink_add_pcs(mac->phylink, &dpaa2_pcs_phylink_ops);
}
Hence, if we are not in DPMAC_LINK_TYPE_PHY, then we never talk to
the PCS, thereby satisfying the requirements of the firmware not to
touch the PCS if it's in FIXED mode.
It seems this is becoming a storm in a tea cup. Please stop.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 0/8] rework phylink interface for split MAC/PCS support
2020-02-26 10:23 ` Russell King - ARM Linux admin
(?)
@ 2020-02-27 20:02 ` David Miller
-1 siblings, 0 replies; 60+ messages in thread
From: David Miller @ 2020-02-27 20:02 UTC (permalink / raw)
To: linux
Cc: andrew, f.fainelli, hkallweit1, linux-doc, thomas.petazzoni,
ioana.ciornei, linux-stm32, corbet, michal.simek, joabreu, kuba,
Mark-MC.Lee, sean.wang, alexandre.torgue, hauke,
radhey.shyam.pandey, linux-mediatek, john, matthias.bgg,
peppe.cavallaro, linux-arm-kernel, netdev, vivien.didelot,
mcoquelin.stm32, olteanv, nbd
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Date: Wed, 26 Feb 2020 10:23:12 +0000
> The following series changes the phylink interface to allow us to
> better support split MAC / MAC PCS setups. The fundamental change
> required for this turns out to be quite simple.
>
> Today, mac_config() is used for everything to do with setting the
> parameters for the MAC, and mac_link_up() is used to inform the
> MAC driver that the link is now up (and so to allow packet flow.)
> mac_config() also has had a few implementation issues, with folk
> who believe that members such as "speed" and "duplex" are always
> valid, where "link" gets used inappropriately, etc.
>
> With the proposed patches, all this changes subtly - but in a
> backwards compatible way at this stage.
>
> We pass the the full resolved link state (speed, duplex, pause) to
> mac_link_up(), and it is now guaranteed that these parameters to
> this function will always be valid (no more SPEED_UNKNOWN or
> DUPLEX_UNKNOWN here - unless phylink is fed with such things.)
>
> Drivers should convert over to using the state in mac_link_up()
> rather than configuring the speed, duplex and pause in the
> mac_config() method. The patch series includes a number of MAC
> drivers which I've thought have been easy targets - I've left the
> remainder as I think they need maintainer input. However, *all*
> drivers will need conversion for future phylink development.
>
> v2: add ocelot/felix and qca/ar9331 DSA drivers to patch 2, add
> received tested-by so far.
In order to end the storm in a teacup, I've applied this series.
:-)
Thanks Russell.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 0/8] rework phylink interface for split MAC/PCS support
@ 2020-02-27 20:02 ` David Miller
0 siblings, 0 replies; 60+ messages in thread
From: David Miller @ 2020-02-27 20:02 UTC (permalink / raw)
To: linux
Cc: andrew, linux-doc, thomas.petazzoni, ioana.ciornei, linux-stm32,
f.fainelli, corbet, michal.simek, joabreu, kuba, Mark-MC.Lee,
sean.wang, alexandre.torgue, hauke, radhey.shyam.pandey,
linux-mediatek, john, matthias.bgg, peppe.cavallaro,
linux-arm-kernel, netdev, vivien.didelot, mcoquelin.stm32, nbd,
olteanv, hkallweit1
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Date: Wed, 26 Feb 2020 10:23:12 +0000
> The following series changes the phylink interface to allow us to
> better support split MAC / MAC PCS setups. The fundamental change
> required for this turns out to be quite simple.
>
> Today, mac_config() is used for everything to do with setting the
> parameters for the MAC, and mac_link_up() is used to inform the
> MAC driver that the link is now up (and so to allow packet flow.)
> mac_config() also has had a few implementation issues, with folk
> who believe that members such as "speed" and "duplex" are always
> valid, where "link" gets used inappropriately, etc.
>
> With the proposed patches, all this changes subtly - but in a
> backwards compatible way at this stage.
>
> We pass the the full resolved link state (speed, duplex, pause) to
> mac_link_up(), and it is now guaranteed that these parameters to
> this function will always be valid (no more SPEED_UNKNOWN or
> DUPLEX_UNKNOWN here - unless phylink is fed with such things.)
>
> Drivers should convert over to using the state in mac_link_up()
> rather than configuring the speed, duplex and pause in the
> mac_config() method. The patch series includes a number of MAC
> drivers which I've thought have been easy targets - I've left the
> remainder as I think they need maintainer input. However, *all*
> drivers will need conversion for future phylink development.
>
> v2: add ocelot/felix and qca/ar9331 DSA drivers to patch 2, add
> received tested-by so far.
In order to end the storm in a teacup, I've applied this series.
:-)
Thanks Russell.
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 0/8] rework phylink interface for split MAC/PCS support
@ 2020-02-27 20:02 ` David Miller
0 siblings, 0 replies; 60+ messages in thread
From: David Miller @ 2020-02-27 20:02 UTC (permalink / raw)
To: linux
Cc: andrew, linux-doc, thomas.petazzoni, ioana.ciornei, linux-stm32,
f.fainelli, corbet, michal.simek, joabreu, kuba, Mark-MC.Lee,
sean.wang, alexandre.torgue, hauke, radhey.shyam.pandey,
linux-mediatek, john, matthias.bgg, peppe.cavallaro,
linux-arm-kernel, netdev, vivien.didelot, mcoquelin.stm32, nbd,
olteanv, hkallweit1
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Date: Wed, 26 Feb 2020 10:23:12 +0000
> The following series changes the phylink interface to allow us to
> better support split MAC / MAC PCS setups. The fundamental change
> required for this turns out to be quite simple.
>
> Today, mac_config() is used for everything to do with setting the
> parameters for the MAC, and mac_link_up() is used to inform the
> MAC driver that the link is now up (and so to allow packet flow.)
> mac_config() also has had a few implementation issues, with folk
> who believe that members such as "speed" and "duplex" are always
> valid, where "link" gets used inappropriately, etc.
>
> With the proposed patches, all this changes subtly - but in a
> backwards compatible way at this stage.
>
> We pass the the full resolved link state (speed, duplex, pause) to
> mac_link_up(), and it is now guaranteed that these parameters to
> this function will always be valid (no more SPEED_UNKNOWN or
> DUPLEX_UNKNOWN here - unless phylink is fed with such things.)
>
> Drivers should convert over to using the state in mac_link_up()
> rather than configuring the speed, duplex and pause in the
> mac_config() method. The patch series includes a number of MAC
> drivers which I've thought have been easy targets - I've left the
> remainder as I think they need maintainer input. However, *all*
> drivers will need conversion for future phylink development.
>
> v2: add ocelot/felix and qca/ar9331 DSA drivers to patch 2, add
> received tested-by so far.
In order to end the storm in a teacup, I've applied this series.
:-)
Thanks Russell.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 0/8] rework phylink interface for split MAC/PCS support
2020-02-27 20:02 ` David Miller
(?)
@ 2020-02-27 22:13 ` Russell King - ARM Linux admin
-1 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-27 22:13 UTC (permalink / raw)
To: David Miller
Cc: andrew, linux-doc, thomas.petazzoni, ioana.ciornei, linux-stm32,
f.fainelli, corbet, michal.simek, joabreu, kuba, Mark-MC.Lee,
sean.wang, alexandre.torgue, hauke, radhey.shyam.pandey,
linux-mediatek, john, matthias.bgg, peppe.cavallaro,
linux-arm-kernel, netdev, vivien.didelot, mcoquelin.stm32, nbd,
olteanv, hkallweit1
On Thu, Feb 27, 2020 at 12:02:54PM -0800, David Miller wrote:
> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Date: Wed, 26 Feb 2020 10:23:12 +0000
>
> > The following series changes the phylink interface to allow us to
> > better support split MAC / MAC PCS setups. The fundamental change
> > required for this turns out to be quite simple.
> >
> > Today, mac_config() is used for everything to do with setting the
> > parameters for the MAC, and mac_link_up() is used to inform the
> > MAC driver that the link is now up (and so to allow packet flow.)
> > mac_config() also has had a few implementation issues, with folk
> > who believe that members such as "speed" and "duplex" are always
> > valid, where "link" gets used inappropriately, etc.
> >
> > With the proposed patches, all this changes subtly - but in a
> > backwards compatible way at this stage.
> >
> > We pass the the full resolved link state (speed, duplex, pause) to
> > mac_link_up(), and it is now guaranteed that these parameters to
> > this function will always be valid (no more SPEED_UNKNOWN or
> > DUPLEX_UNKNOWN here - unless phylink is fed with such things.)
> >
> > Drivers should convert over to using the state in mac_link_up()
> > rather than configuring the speed, duplex and pause in the
> > mac_config() method. The patch series includes a number of MAC
> > drivers which I've thought have been easy targets - I've left the
> > remainder as I think they need maintainer input. However, *all*
> > drivers will need conversion for future phylink development.
> >
> > v2: add ocelot/felix and qca/ar9331 DSA drivers to patch 2, add
> > received tested-by so far.
>
> In order to end the storm in a teacup, I've applied this series.
>
> :-)
>
> Thanks Russell.
Thanks David, I was getting concerned that the teacup might break! :p
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 0/8] rework phylink interface for split MAC/PCS support
@ 2020-02-27 22:13 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-27 22:13 UTC (permalink / raw)
To: David Miller
Cc: andrew, linux-doc, thomas.petazzoni, ioana.ciornei, linux-stm32,
f.fainelli, corbet, michal.simek, hkallweit1, joabreu, kuba,
vivien.didelot, sean.wang, alexandre.torgue, hauke,
radhey.shyam.pandey, linux-mediatek, john, matthias.bgg,
peppe.cavallaro, linux-arm-kernel, netdev, Mark-MC.Lee,
mcoquelin.stm32, olteanv, nbd
On Thu, Feb 27, 2020 at 12:02:54PM -0800, David Miller wrote:
> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Date: Wed, 26 Feb 2020 10:23:12 +0000
>
> > The following series changes the phylink interface to allow us to
> > better support split MAC / MAC PCS setups. The fundamental change
> > required for this turns out to be quite simple.
> >
> > Today, mac_config() is used for everything to do with setting the
> > parameters for the MAC, and mac_link_up() is used to inform the
> > MAC driver that the link is now up (and so to allow packet flow.)
> > mac_config() also has had a few implementation issues, with folk
> > who believe that members such as "speed" and "duplex" are always
> > valid, where "link" gets used inappropriately, etc.
> >
> > With the proposed patches, all this changes subtly - but in a
> > backwards compatible way at this stage.
> >
> > We pass the the full resolved link state (speed, duplex, pause) to
> > mac_link_up(), and it is now guaranteed that these parameters to
> > this function will always be valid (no more SPEED_UNKNOWN or
> > DUPLEX_UNKNOWN here - unless phylink is fed with such things.)
> >
> > Drivers should convert over to using the state in mac_link_up()
> > rather than configuring the speed, duplex and pause in the
> > mac_config() method. The patch series includes a number of MAC
> > drivers which I've thought have been easy targets - I've left the
> > remainder as I think they need maintainer input. However, *all*
> > drivers will need conversion for future phylink development.
> >
> > v2: add ocelot/felix and qca/ar9331 DSA drivers to patch 2, add
> > received tested-by so far.
>
> In order to end the storm in a teacup, I've applied this series.
>
> :-)
>
> Thanks Russell.
Thanks David, I was getting concerned that the teacup might break! :p
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH net-next v2 0/8] rework phylink interface for split MAC/PCS support
@ 2020-02-27 22:13 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 60+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-27 22:13 UTC (permalink / raw)
To: David Miller
Cc: andrew, linux-doc, thomas.petazzoni, ioana.ciornei, linux-stm32,
f.fainelli, corbet, michal.simek, hkallweit1, joabreu, kuba,
vivien.didelot, sean.wang, alexandre.torgue, hauke,
radhey.shyam.pandey, linux-mediatek, john, matthias.bgg,
peppe.cavallaro, linux-arm-kernel, netdev, Mark-MC.Lee,
mcoquelin.stm32, olteanv, nbd
On Thu, Feb 27, 2020 at 12:02:54PM -0800, David Miller wrote:
> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Date: Wed, 26 Feb 2020 10:23:12 +0000
>
> > The following series changes the phylink interface to allow us to
> > better support split MAC / MAC PCS setups. The fundamental change
> > required for this turns out to be quite simple.
> >
> > Today, mac_config() is used for everything to do with setting the
> > parameters for the MAC, and mac_link_up() is used to inform the
> > MAC driver that the link is now up (and so to allow packet flow.)
> > mac_config() also has had a few implementation issues, with folk
> > who believe that members such as "speed" and "duplex" are always
> > valid, where "link" gets used inappropriately, etc.
> >
> > With the proposed patches, all this changes subtly - but in a
> > backwards compatible way at this stage.
> >
> > We pass the the full resolved link state (speed, duplex, pause) to
> > mac_link_up(), and it is now guaranteed that these parameters to
> > this function will always be valid (no more SPEED_UNKNOWN or
> > DUPLEX_UNKNOWN here - unless phylink is fed with such things.)
> >
> > Drivers should convert over to using the state in mac_link_up()
> > rather than configuring the speed, duplex and pause in the
> > mac_config() method. The patch series includes a number of MAC
> > drivers which I've thought have been easy targets - I've left the
> > remainder as I think they need maintainer input. However, *all*
> > drivers will need conversion for future phylink development.
> >
> > v2: add ocelot/felix and qca/ar9331 DSA drivers to patch 2, add
> > received tested-by so far.
>
> In order to end the storm in a teacup, I've applied this series.
>
> :-)
>
> Thanks Russell.
Thanks David, I was getting concerned that the teacup might break! :p
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 60+ messages in thread
end of thread, other threads:[~2020-02-27 22:14 UTC | newest]
Thread overview: 60+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-26 10:23 [PATCH net-next v2 0/8] rework phylink interface for split MAC/PCS support Russell King - ARM Linux admin
2020-02-26 10:23 ` Russell King - ARM Linux admin
2020-02-26 10:23 ` Russell King - ARM Linux admin
2020-02-26 10:23 ` [PATCH net-next v2 1/8] net: phylink: propagate resolved link config via mac_link_up() Russell King
2020-02-26 10:23 ` Russell King
2020-02-26 10:23 ` Russell King
2020-02-26 11:06 ` Vladimir Oltean
2020-02-26 11:06 ` Vladimir Oltean
2020-02-26 11:06 ` Vladimir Oltean
2020-02-26 11:55 ` Russell King - ARM Linux admin
2020-02-26 11:55 ` Russell King - ARM Linux admin
2020-02-26 11:55 ` Russell King - ARM Linux admin
2020-02-26 13:00 ` Vladimir Oltean
2020-02-26 13:00 ` Vladimir Oltean
2020-02-26 13:00 ` Vladimir Oltean
2020-02-26 13:36 ` Russell King - ARM Linux admin
2020-02-26 13:36 ` Russell King - ARM Linux admin
2020-02-26 13:36 ` Russell King - ARM Linux admin
2020-02-26 18:21 ` Vladimir Oltean
2020-02-26 18:21 ` Vladimir Oltean
2020-02-26 18:21 ` Vladimir Oltean
2020-02-26 18:22 ` Vladimir Oltean
2020-02-26 18:22 ` Vladimir Oltean
2020-02-26 18:22 ` Vladimir Oltean
2020-02-26 18:25 ` Russell King - ARM Linux admin
2020-02-26 18:25 ` Russell King - ARM Linux admin
2020-02-26 18:25 ` Russell King - ARM Linux admin
2020-02-26 18:32 ` Ioana Ciornei
2020-02-26 18:32 ` Ioana Ciornei
2020-02-26 18:32 ` Ioana Ciornei
2020-02-26 19:11 ` Russell King - ARM Linux admin
2020-02-26 19:11 ` Russell King - ARM Linux admin
2020-02-26 19:11 ` Russell King - ARM Linux admin
2020-02-26 10:23 ` [PATCH net-next v2 2/8] net: dsa: " Russell King
2020-02-26 10:23 ` Russell King
2020-02-26 10:23 ` Russell King
2020-02-26 10:23 ` [PATCH net-next v2 3/8] net: mv88e6xxx: use resolved link config in mac_link_up() Russell King
2020-02-26 10:23 ` Russell King
2020-02-26 10:23 ` Russell King
2020-02-26 10:23 ` [PATCH net-next v2 4/8] net: axienet: " Russell King
2020-02-26 10:23 ` Russell King
2020-02-26 10:23 ` Russell King
2020-02-26 10:24 ` [PATCH net-next v2 5/8] net: dpaa2-mac: " Russell King
2020-02-26 10:24 ` Russell King
2020-02-26 10:24 ` Russell King
2020-02-26 10:24 ` [PATCH net-next v2 6/8] net: macb: " Russell King
2020-02-26 10:24 ` Russell King
2020-02-26 10:24 ` Russell King
2020-02-26 10:24 ` [PATCH net-next v2 7/8] net: mvneta: " Russell King
2020-02-26 10:24 ` Russell King
2020-02-26 10:24 ` Russell King
2020-02-26 10:24 ` [PATCH net-next v2 8/8] net: mvpp2: " Russell King
2020-02-26 10:24 ` Russell King
2020-02-26 10:24 ` Russell King
2020-02-27 20:02 ` [PATCH net-next v2 0/8] rework phylink interface for split MAC/PCS support David Miller
2020-02-27 20:02 ` David Miller
2020-02-27 20:02 ` David Miller
2020-02-27 22:13 ` Russell King - ARM Linux admin
2020-02-27 22:13 ` Russell King - ARM Linux admin
2020-02-27 22:13 ` Russell King - ARM Linux admin
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.