| Message ID | 20240524210304.9164-3-fancer.lancer@gmail.com (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [RFC,net-next,1/3] net: stmmac: Prevent RGSMIIIS IRQs flood | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/apply | fail | Patch does not apply to net-next-0 |
On Sat, May 25, 2024 at 12:02:59AM +0300, Serge Semin wrote: > First of all the flags are never set by any of the driver parts. If nobody > have them set then the respective statements will always have the same > result. Thus the statements can be simplified or even dropped with no risk > to break things. > > Secondly shall any of the TBI or RTBI flag is set the MDIO-bus > registration will be bypassed. Why? It really seems weird. It's perfectly > fine to have a TBI/RTBI-capable PHY configured over the MDIO bus > interface. > > Based on the notes above the TBI/RTBI PCS flags can be freely dropped thus > simplifying the driver code. > > Signed-off-by: Serge Semin <fancer.lancer@gmail.com> I think this patch can come first in the series, along with another few patches that remove stuff. Any objection? Thanks.
On Tue, May 28, 2024 at 11:23:05AM +0100, Russell King (Oracle) wrote: > On Sat, May 25, 2024 at 12:02:59AM +0300, Serge Semin wrote: > > First of all the flags are never set by any of the driver parts. If nobody > > have them set then the respective statements will always have the same > > result. Thus the statements can be simplified or even dropped with no risk > > to break things. > > > > Secondly shall any of the TBI or RTBI flag is set the MDIO-bus > > registration will be bypassed. Why? It really seems weird. It's perfectly > > fine to have a TBI/RTBI-capable PHY configured over the MDIO bus > > interface. > > > > Based on the notes above the TBI/RTBI PCS flags can be freely dropped thus > > simplifying the driver code. > > > > Signed-off-by: Serge Semin <fancer.lancer@gmail.com> > > I think this patch can come first in the series, along with another > few patches that remove stuff. Any objection? No objection. -Serge(y) > > Thanks. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h index b02b905bc892..40a930ea4ff3 100644 --- a/drivers/net/ethernet/stmicro/stmmac/common.h +++ b/drivers/net/ethernet/stmicro/stmmac/common.h @@ -268,8 +268,6 @@ struct stmmac_safety_stats { /* PCS defines */ #define STMMAC_PCS_RGMII (1 << 0) #define STMMAC_PCS_SGMII (1 << 1) -#define STMMAC_PCS_TBI (1 << 2) -#define STMMAC_PCS_RTBI (1 << 3) #define SF_DMA_MODE 1 /* DMA STORE-AND-FORWARD Operation Mode */ diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 6c4e90b1fea3..06f95dfdf09e 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -471,13 +471,6 @@ bool stmmac_eee_init(struct stmmac_priv *priv) { int eee_tw_timer = priv->eee_tw_timer; - /* Using PCS we cannot dial with the phy registers at this stage - * so we do not support extra feature like EEE. - */ - if (priv->hw->pcs == STMMAC_PCS_TBI || - priv->hw->pcs == STMMAC_PCS_RTBI) - return false; - /* Check if MAC core supports the EEE feature. */ if (!priv->dma_cap.eee) return false; @@ -3945,9 +3938,7 @@ static int __stmmac_open(struct net_device *dev, if (ret < 0) return ret; - if (priv->hw->pcs != STMMAC_PCS_TBI && - priv->hw->pcs != STMMAC_PCS_RTBI && - (!priv->hw->xpcs || + if ((!priv->hw->xpcs || xpcs_get_an_mode(priv->hw->xpcs, mode) != DW_AN_C73) && !priv->hw->lynx_pcs) { ret = stmmac_init_phy(dev); @@ -7724,16 +7715,12 @@ int stmmac_dvr_probe(struct device *device, if (!pm_runtime_enabled(device)) pm_runtime_enable(device); - if (priv->hw->pcs != STMMAC_PCS_TBI && - priv->hw->pcs != STMMAC_PCS_RTBI) { - /* MDIO bus Registration */ - ret = stmmac_mdio_register(ndev); - if (ret < 0) { - dev_err_probe(priv->device, ret, - "%s: MDIO bus (id: %d) registration failed\n", - __func__, priv->plat->bus_id); - goto error_mdio_register; - } + ret = stmmac_mdio_register(ndev); + if (ret < 0) { + dev_err_probe(priv->device, ret, + "MDIO bus (id: %d) registration failed\n", + priv->plat->bus_id); + goto error_mdio_register; } if (priv->plat->speed_mode_2500) @@ -7776,9 +7763,7 @@ int stmmac_dvr_probe(struct device *device, phylink_destroy(priv->phylink); error_xpcs_setup: error_phy_setup: - if (priv->hw->pcs != STMMAC_PCS_TBI && - priv->hw->pcs != STMMAC_PCS_RTBI) - stmmac_mdio_unregister(ndev); + stmmac_mdio_unregister(ndev); error_mdio_register: stmmac_napi_del(ndev); error_hw_init: @@ -7817,9 +7802,9 @@ void stmmac_dvr_remove(struct device *dev) if (priv->plat->stmmac_rst) reset_control_assert(priv->plat->stmmac_rst); reset_control_assert(priv->plat->stmmac_ahb_rst); - if (priv->hw->pcs != STMMAC_PCS_TBI && - priv->hw->pcs != STMMAC_PCS_RTBI) - stmmac_mdio_unregister(ndev); + + stmmac_mdio_unregister(ndev); + destroy_workqueue(priv->wq); mutex_destroy(&priv->lock); bitmap_free(priv->af_xdp_zc_qps);
First of all the flags are never set by any of the driver parts. If nobody have them set then the respective statements will always have the same result. Thus the statements can be simplified or even dropped with no risk to break things. Secondly shall any of the TBI or RTBI flag is set the MDIO-bus registration will be bypassed. Why? It really seems weird. It's perfectly fine to have a TBI/RTBI-capable PHY configured over the MDIO bus interface. Based on the notes above the TBI/RTBI PCS flags can be freely dropped thus simplifying the driver code. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> --- drivers/net/ethernet/stmicro/stmmac/common.h | 2 - .../net/ethernet/stmicro/stmmac/stmmac_main.c | 37 ++++++------------- 2 files changed, 11 insertions(+), 28 deletions(-)