Message ID | 20240412180340.7965-3-fancer.lancer@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | net: stmmac: Fix MAC-capabilities procedure | expand |
On Fri, 12 Apr 2024, Serge Semin wrote: > It's possible to have the maximum link speed being artificially limited on > the platform-specific basis. It's done either by setting up the > plat_stmmacenet_data::max_speed field or by specifying the "max-speed" > DT-property. In such cases it's required that any specific > MAC-capabilities re-initializations would take the limit into account. In > particular the link speed capabilities may change during the number of > active Tx/Rx queues re-initialization. But the currently implemented > procedure doesn't take the speed limit into account. > > Fix that by calling phylink_limit_mac_speed() in the > stmmac_reinit_queues() method if the speed limitation was required in the > same way as it's done in the stmmac_phy_setup() function. > > Fixes: 95201f36f395 ("net: stmmac: update MAC capabilities when tx queues are updated") > Signed-off-by: Serge Semin <fancer.lancer@gmail.com> > --- > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > index dd58c21b53ee..b8a1f02398ee 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > @@ -7328,6 +7328,7 @@ int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt) > { > struct stmmac_priv *priv = netdev_priv(dev); > int ret = 0, i; > + int max_speed; > > if (netif_running(dev)) > stmmac_release(dev); > @@ -7343,6 +7344,10 @@ int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt) > > stmmac_mac_phylink_get_caps(priv); > > + max_speed = priv->plat->max_speed; > + if (max_speed) > + phylink_limit_mac_speed(&priv->phylink_config, max_speed); > + > stmmac_napi_add(dev); > > if (netif_running(dev)) > -- > 2.43.0 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > Reviewed-by: Romain Gantois <romain.gantois@bootlin.com>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index dd58c21b53ee..b8a1f02398ee 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -7328,6 +7328,7 @@ int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt) { struct stmmac_priv *priv = netdev_priv(dev); int ret = 0, i; + int max_speed; if (netif_running(dev)) stmmac_release(dev); @@ -7343,6 +7344,10 @@ int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt) stmmac_mac_phylink_get_caps(priv); + max_speed = priv->plat->max_speed; + if (max_speed) + phylink_limit_mac_speed(&priv->phylink_config, max_speed); + stmmac_napi_add(dev); if (netif_running(dev))
It's possible to have the maximum link speed being artificially limited on the platform-specific basis. It's done either by setting up the plat_stmmacenet_data::max_speed field or by specifying the "max-speed" DT-property. In such cases it's required that any specific MAC-capabilities re-initializations would take the limit into account. In particular the link speed capabilities may change during the number of active Tx/Rx queues re-initialization. But the currently implemented procedure doesn't take the speed limit into account. Fix that by calling phylink_limit_mac_speed() in the stmmac_reinit_queues() method if the speed limitation was required in the same way as it's done in the stmmac_phy_setup() function. Fixes: 95201f36f395 ("net: stmmac: update MAC capabilities when tx queues are updated") Signed-off-by: Serge Semin <fancer.lancer@gmail.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +++++ 1 file changed, 5 insertions(+)