[PATCH net-next] net: stmmac: qcom-ethqos: add ethqos_pcs_set_inband()

[Simon Horman]

On Sat, Jun 14, 2025 at 07:22:04PM +0100, Russell King (Oracle) wrote:
> On Sat, Jun 14, 2025 at 04:35:12PM +0100, Simon Horman wrote:
> > On Thu, Jun 12, 2025 at 05:16:30PM +0100, Russell King (Oracle) wrote:
> > > Add ethqos_pcs_set_inband() to improve readability, and to allow future
> > > changes when phylink PCS support is properly merged.
> > > 
> > > Reviewed-by: Andrew Halaney <ahalaney at redhat.com>
> > > Tested-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org> # sa8775p-ride-r3
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> > 
> > Thanks Russell,
> > 
> > The nit below notwithstanding this looks good to me.
> > 
> > Reviewed-by: Simon Horman <horms at kernel.org>
> > 
> > > ---
> > >  .../net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 13 +++++++++----
> > >  1 file changed, 9 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> > > index e30bdf72331a..2e398574c7a7 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> > > @@ -622,6 +622,11 @@ static void ethqos_set_serdes_speed(struct qcom_ethqos *ethqos, int speed)
> > >  	}
> > >  }
> > >  
> > > +static void ethqos_pcs_set_inband(struct stmmac_priv *priv, bool enable)
> > > +{
> > > +	stmmac_pcs_ctrl_ane(priv, priv->ioaddr, enable, 0, 0);
> > 
> > FWIIW, I would have gone for the following, as all the type of
> > three of the trailing parameters is bool.
> > 
> > 	stmmac_pcs_ctrl_ane(priv, priv->ioaddr, enable, false, false);
> 
> So the original code:
> 
>             stmmac_pcs_ctrl_ane(priv, priv->ioaddr, 0, 0, 0);
>             stmmac_pcs_ctrl_ane(priv, priv->ioaddr, 1, 0, 0);
>             stmmac_pcs_ctrl_ane(priv, priv->ioaddr, 1, 0, 0);
>             stmmac_pcs_ctrl_ane(priv, priv->ioaddr, 1, 0, 0);
> 
> While one could convert the last two arguments to true/false, I'd prefer
> leaving them as is, as less change means less chance to introduce a bug.

Sure. No objections on my side.