| Message ID | E1sBvJl-00EHyQ-QG@rmk-PC.armlinux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | net: stmmac: cleanups | expand |
On Tue, May 28, 2024 at 12:48:37PM +0100, Russell King wrote: > From: Serge Semin <fancer.lancer@gmail.com> > > 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. Likely by mistake the vast majority of the original patch content has been missing here: https://lore.kernel.org/netdev/20240524210304.9164-3-fancer.lancer@gmail.com/ -Serge(y) > > Signed-off-by: Serge Semin <fancer.lancer@gmail.com> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > index b3afc7cb7d72..e01340034d50 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > @@ -7833,10 +7833,7 @@ void stmmac_dvr_remove(struct device *dev) > reset_control_assert(priv->plat->stmmac_ahb_rst); > > stmmac_pcs_clean(ndev); > - > - 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); > -- > 2.30.2 >
On Tue, May 28, 2024 at 03:26:10PM +0300, Serge Semin wrote: > On Tue, May 28, 2024 at 12:48:37PM +0100, Russell King wrote: > > From: Serge Semin <fancer.lancer@gmail.com> > > > > 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. > > Likely by mistake the vast majority of the original patch content has > been missing here: > https://lore.kernel.org/netdev/20240524210304.9164-3-fancer.lancer@gmail.com/ I really can't explain this, other than git doing something weird. There is no reason that just one hunk that conflicted from a patch would've appeared. Should've been as per the below, which it will be when I post v2. Thanks for spotting! 8<=== From: Serge Semin <fancer.lancer@gmail.com> Subject: [PATCH net-next] net: stmmac: Drop TBI/RTBI PCS flags 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> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/net/ethernet/stmicro/stmmac/common.h | 2 -- .../net/ethernet/stmicro/stmmac/stmmac_main.c | 35 +++++-------------- 2 files changed, 9 insertions(+), 28 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h index 9cd62b2110a1..cd36ff4da68c 100644 --- a/drivers/net/ethernet/stmicro/stmmac/common.h +++ b/drivers/net/ethernet/stmicro/stmmac/common.h @@ -271,8 +271,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 b3afc7cb7d72..3ab93f89be90 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; @@ -3953,9 +3946,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)) { ret = stmmac_init_phy(dev); if (ret) { @@ -7739,16 +7730,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) @@ -7790,9 +7777,7 @@ int stmmac_dvr_probe(struct device *device, error_phy_setup: stmmac_pcs_clean(ndev); error_pcs_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: @@ -7833,10 +7818,8 @@ void stmmac_dvr_remove(struct device *dev) reset_control_assert(priv->plat->stmmac_ahb_rst); stmmac_pcs_clean(ndev); + stmmac_mdio_unregister(ndev); - if (priv->hw->pcs != STMMAC_PCS_TBI && - priv->hw->pcs != STMMAC_PCS_RTBI) - stmmac_mdio_unregister(ndev); destroy_workqueue(priv->wq); mutex_destroy(&priv->lock); bitmap_free(priv->af_xdp_zc_qps);
On Tue, May 28, 2024 at 02:20:27PM GMT, Russell King (Oracle) wrote: > On Tue, May 28, 2024 at 03:26:10PM +0300, Serge Semin wrote: > > On Tue, May 28, 2024 at 12:48:37PM +0100, Russell King wrote: > > > From: Serge Semin <fancer.lancer@gmail.com> > > > > > > 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. > > > > Likely by mistake the vast majority of the original patch content has > > been missing here: > > https://lore.kernel.org/netdev/20240524210304.9164-3-fancer.lancer@gmail.com/ > > I really can't explain this, other than git doing something weird. There > is no reason that just one hunk that conflicted from a patch would've > appeared. Should've been as per the below, which it will be when I post > v2. Thanks for spotting! > > 8<=== > From: Serge Semin <fancer.lancer@gmail.com> > Subject: [PATCH net-next] net: stmmac: Drop TBI/RTBI PCS flags > > 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> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index b3afc7cb7d72..e01340034d50 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -7833,10 +7833,7 @@ void stmmac_dvr_remove(struct device *dev) reset_control_assert(priv->plat->stmmac_ahb_rst); stmmac_pcs_clean(ndev); - - 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);