diff mbox series

[net-next,v4,06/11] net: stmmac: resetup XPCS according to the new interface mode

Message ID 20240129130253.1400707-7-yong.liang.choong@linux.intel.com (mailing list archive)
State Changes Requested
Headers show
Series Enable SGMII and 2500BASEX interface mode switching for Intel platforms | expand

Commit Message

Choong Yong Liang Jan. 29, 2024, 1:02 p.m. UTC
XPCS creation will map the configuration for the provided interface mode.
Then XPCS will operate according to the interface mode.

When the interface mode changes, XPCS is required to map the configuration
to the new interface mode and destroy the old interface mode where it
is not in use.

Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++--
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  7 +++----
 3 files changed, 15 insertions(+), 7 deletions(-)

Comments

Russell King (Oracle) Jan. 30, 2024, 10:21 a.m. UTC | #1
On Mon, Jan 29, 2024 at 09:02:48PM +0800, Choong Yong Liang wrote:
> XPCS creation will map the configuration for the provided interface mode.
> Then XPCS will operate according to the interface mode.
> 
> When the interface mode changes, XPCS is required to map the configuration
> to the new interface mode and destroy the old interface mode where it
> is not in use.
> 
> Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 +-
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++--
>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  7 +++----
>  3 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> index f155e4841c62..886efd26991e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> @@ -357,7 +357,7 @@ enum stmmac_state {
>  int stmmac_mdio_unregister(struct net_device *ndev);
>  int stmmac_mdio_register(struct net_device *ndev);
>  int stmmac_mdio_reset(struct mii_bus *mii);
> -int stmmac_xpcs_setup(struct mii_bus *mii);
> +int stmmac_xpcs_setup(struct mii_bus *mii, phy_interface_t interface);
>  void stmmac_set_ethtool_ops(struct net_device *netdev);
>  
>  int stmmac_init_tstamp_counter(struct stmmac_priv *priv, u32 systime_flags);
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 00af5a4195fd..50429c985441 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -941,8 +941,17 @@ static struct phylink_pcs *stmmac_mac_select_pcs(struct phylink_config *config,
>  {
>  	struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
>  
> -	if (priv->hw->xpcs)
> +	if (priv->hw->xpcs) {
> +		if (interface != PHY_INTERFACE_MODE_NA &&
> +		    interface != priv->plat->phy_interface) {
> +			/* When there are major changes, we reconfigure
> +			 * the setup for xpcs according to the interface.
> +			 */
> +			xpcs_destroy(priv->hw->xpcs);
> +			stmmac_xpcs_setup(priv->mii, interface);

NAK. Absolutely not. You haven't read the phylink documentation, nor
understood how phylink works.

Since you haven't read the phylink documentation, I'm not going to
waste any more time reviewing this series since you haven't done your
side of the bargin here.
Choong Yong Liang Feb. 1, 2024, 5:10 a.m. UTC | #2
On 30/1/2024 6:21 pm, Russell King (Oracle) wrote:
> NAK. Absolutely not. You haven't read the phylink documentation, nor
> understood how phylink works.
> 
> Since you haven't read the phylink documentation, I'm not going to
> waste any more time reviewing this series since you haven't done your
> side of the bargin here.
> 
Hi Russell,

Sorry that previously I only studied the phylink based on the `phylink.h` 
itself. I think it might not be sufficient. I did search through the 
internet and found the phylink document from kernel.org 
(https://docs.kernel.org/networking/sfp-phylink.html). Kindly let me know 
if there are any other phylink documents I might have overlooked.

According to the phylink document from kernel.org, it does mention that 
"phylink is a mechanism to support hot-pluggable networking modules 
directly connected to a MAC without needing to re-initialise the adapter on 
hot-plug events." I realize I should not destroy and reinitialize the PCS.
Instead, I plan to follow the implementation in "net: macb: use 
.mac_select_pcs() interface" 
(https://lore.kernel.org/netdev/E1n568J-002SZX-Gr@rmk-PC.armlinux.org.uk/T/). 
This involves initializing the required PCS during the MAC probe and 
querying the PCS based on the interface.

Kindly let me know if I've overlooked anything in this proposed solution.
Russell King (Oracle) Feb. 1, 2024, 8:38 a.m. UTC | #3
On Thu, Feb 01, 2024 at 01:10:05PM +0800, Choong Yong Liang wrote:
> 
> 
> On 30/1/2024 6:21 pm, Russell King (Oracle) wrote:
> > NAK. Absolutely not. You haven't read the phylink documentation, nor
> > understood how phylink works.
> > 
> > Since you haven't read the phylink documentation, I'm not going to
> > waste any more time reviewing this series since you haven't done your
> > side of the bargin here.
> > 
> Hi Russell,
> 
> Sorry that previously I only studied the phylink based on the `phylink.h`
> itself.

From phylink.h:

/**
 * mac_select_pcs: Select a PCS for the interface mode.
 * @config: a pointer to a &struct phylink_config.
 * @interface: PHY interface mode for PCS
 *
 * Return the &struct phylink_pcs for the specified interface mode, or
 * NULL if none is required, or an error pointer on error.
 *
 * This must not modify any state. It is used to query which PCS should
 * be used. Phylink will use this during validation to ensure that the
 * configuration is valid, and when setting a configuration to internally
 * set the PCS that will be used.
 */

Note the "This must not modify any state." statement. By reinitialising
the PCS in this method, you are violating that statement.

This requirement is because this method will be called by
phylink_validate_mac_and_pcs() at various times, potentially for each
and every interface that stmmac supports, which will lead to you
reinitialising the PCS, killing the link, each time we ask the MAC for
a PCS, whether we are going to make use of it in that mode or not.

You can not do this. Sorry. Hard NAK for this approach.
Choong Yong Liang Feb. 2, 2024, 3 a.m. UTC | #4
On 1/2/2024 4:38 pm, Russell King (Oracle) wrote:
> Note the "This must not modify any state." statement. By reinitialising
> the PCS in this method, you are violating that statement.
> 
> This requirement is because this method will be called by
> phylink_validate_mac_and_pcs() at various times, potentially for each
> and every interface that stmmac supports, which will lead to you
> reinitialising the PCS, killing the link, each time we ask the MAC for
> a PCS, whether we are going to make use of it in that mode or not.
> 
> You can not do this. Sorry. Hard NAK for this approach.
> 
Thank you for taking the time to review, got your concerns, and I'll 
address the following concerns before submitting a new patch series:

1. Remove allow_switch_interface and have the PHY driver fill in 
phydev->possible_interfaces.
2. Rework on the PCS to have similar implementation with the following 
patch "net: macb: use .mac_select_pcs() interface" 
(https://lore.kernel.org/netdev/E1n568J-002SZX-Gr@rmk-PC.armlinux.org.uk/T/).

Kindly let me know if there are any additional concerns or suggestions.
Russell King (Oracle) Feb. 2, 2024, 8:50 a.m. UTC | #5
On Fri, Feb 02, 2024 at 11:00:58AM +0800, Choong Yong Liang wrote:
> 
> 
> On 1/2/2024 4:38 pm, Russell King (Oracle) wrote:
> > Note the "This must not modify any state." statement. By reinitialising
> > the PCS in this method, you are violating that statement.
> > 
> > This requirement is because this method will be called by
> > phylink_validate_mac_and_pcs() at various times, potentially for each
> > and every interface that stmmac supports, which will lead to you
> > reinitialising the PCS, killing the link, each time we ask the MAC for
> > a PCS, whether we are going to make use of it in that mode or not.
> > 
> > You can not do this. Sorry. Hard NAK for this approach.
> > 
> Thank you for taking the time to review, got your concerns, and I'll address
> the following concerns before submitting a new patch series:
> 
> 1. Remove allow_switch_interface and have the PHY driver fill in
> phydev->possible_interfaces.

Yes please.

> 2. Rework on the PCS to have similar implementation with the following patch
> "net: macb: use .mac_select_pcs() interface"
> (https://lore.kernel.org/netdev/E1n568J-002SZX-Gr@rmk-PC.armlinux.org.uk/T/).

mac_select_pcs() is about returning to phylink the PCS that the MAC
needs to use for the specified interface mode, or NULL if no PCS is
required, nothing more, nothing less.

Plase do not copy that mac_select_pcs() implementation - changing the
"ops" underneath phylink is no longer permitted.
Choong Yong Liang Feb. 15, 2024, 3:14 a.m. UTC | #6
On 2/2/2024 4:50 pm, Russell King (Oracle) wrote:
>> Thank you for taking the time to review, got your concerns, and I'll address
>> the following concerns before submitting a new patch series:
>>
>> 1. Remove allow_switch_interface and have the PHY driver fill in
>> phydev->possible_interfaces.
> 
> Yes please.
> 

Hi Russell,

I regret to inform you that I didn't implement everything exactly as 
proposed in the new patch series. My intention was to simplify the series, 
focusing solely on managing SGMII and 2500BASE-X interface mode switching. 
The recommendation to have the PHY driver fill in 
"phydev->possible_interfaces" will be addressed in a separate patch 
submission. I hope this is acceptable.

In the new patch series, I removed "allow_switch_interface" patches. The 
current solution continues to work with PHYs that are C45 and follow the 
legacy path, such as Marvell Alaska 88E2110. For the upcoming patch series, 
I will implement "phydev->possible_interfaces" for C22 and C45 PHYs.


>> 2. Rework on the PCS to have similar implementation with the following patch
>> "net: macb: use .mac_select_pcs() interface"
>> (https://lore.kernel.org/netdev/E1n568J-002SZX-Gr@rmk-PC.armlinux.org.uk/T/).
> 
> mac_select_pcs() is about returning to phylink the PCS that the MAC
> needs to use for the specified interface mode, or NULL if no PCS is
> required, nothing more, nothing less.
> 
> Plase do not copy that mac_select_pcs() implementation - changing the
> "ops" underneath phylink is no longer permitted.
> 

Upon further examination, I discovered that no change is required for the 
"mac_select_pcs()" function; we can still use the same PCS. According to 
the XPCS datasheet, a soft reset is necessary to re-initiate Clause 37 
auto-negotiation when switching to SGMII interface mode. This is the only 
setting required for properly configuring the SGMII interface mode, and 
nothing extra is needed for 2500BASE-X configuration.

In the new patch series, I removed "mac_select_pcs()" related patches and 
added a "xpcs_soft_reset()" patch for the XPCS.
diff mbox series

Patch

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index f155e4841c62..886efd26991e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -357,7 +357,7 @@  enum stmmac_state {
 int stmmac_mdio_unregister(struct net_device *ndev);
 int stmmac_mdio_register(struct net_device *ndev);
 int stmmac_mdio_reset(struct mii_bus *mii);
-int stmmac_xpcs_setup(struct mii_bus *mii);
+int stmmac_xpcs_setup(struct mii_bus *mii, phy_interface_t interface);
 void stmmac_set_ethtool_ops(struct net_device *netdev);
 
 int stmmac_init_tstamp_counter(struct stmmac_priv *priv, u32 systime_flags);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 00af5a4195fd..50429c985441 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -941,8 +941,17 @@  static struct phylink_pcs *stmmac_mac_select_pcs(struct phylink_config *config,
 {
 	struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
 
-	if (priv->hw->xpcs)
+	if (priv->hw->xpcs) {
+		if (interface != PHY_INTERFACE_MODE_NA &&
+		    interface != priv->plat->phy_interface) {
+			/* When there are major changes, we reconfigure
+			 * the setup for xpcs according to the interface.
+			 */
+			xpcs_destroy(priv->hw->xpcs);
+			stmmac_xpcs_setup(priv->mii, interface);
+		}
 		return &priv->hw->xpcs->pcs;
+	}
 
 	if (priv->hw->lynx_pcs)
 		return priv->hw->lynx_pcs;
@@ -7737,7 +7746,7 @@  int stmmac_dvr_probe(struct device *device,
 		priv->plat->speed_mode_2500(ndev, priv->plat->bsp_priv);
 
 	if (priv->plat->mdio_bus_data && priv->plat->mdio_bus_data->has_xpcs) {
-		ret = stmmac_xpcs_setup(priv->mii);
+		ret = stmmac_xpcs_setup(priv->mii, priv->plat->phy_interface);
 		if (ret)
 			goto error_xpcs_setup;
 	}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index 0542cfd1817e..1be144f3dee9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -495,19 +495,18 @@  int stmmac_mdio_reset(struct mii_bus *bus)
 	return 0;
 }
 
-int stmmac_xpcs_setup(struct mii_bus *bus)
+int stmmac_xpcs_setup(struct mii_bus *bus, phy_interface_t interface)
 {
 	struct net_device *ndev = bus->priv;
 	struct stmmac_priv *priv;
 	struct dw_xpcs *xpcs;
-	int mode, addr;
+	int addr;
 
 	priv = netdev_priv(ndev);
-	mode = priv->plat->phy_interface;
 
 	/* Try to probe the XPCS by scanning all addresses. */
 	for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
-		xpcs = xpcs_create_mdiodev(bus, addr, mode);
+		xpcs = xpcs_create_mdiodev(bus, addr, interface);
 		if (IS_ERR(xpcs))
 			continue;