Re: [PATCH net-next 4/6] net: stmmac: rk: use stmmac_set_tx_clk_gmii()

From: Serge Semin <fancer.lancer@gmail.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>,
	 Jose Abreu <joabreu@synopsys.com>,
	Alexei Starovoitov <ast@kernel.org>,
	bpf@vger.kernel.org,  Daniel Borkmann <daniel@iogearbox.net>,
	"David S. Miller" <davem@davemloft.net>,
	 Emil Renner Berthing <kernel@esmil.dk>,
	Eric Dumazet <edumazet@google.com>,
	 Fabio Estevam <festevam@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	 Jesper Dangaard Brouer <hawk@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	 linux-arm-kernel@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	 Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	netdev@vger.kernel.org, NXP Linux Team <linux-imx@nxp.com>,
	 Paolo Abeni <pabeni@redhat.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	 Samin Guo <samin.guo@starfivetech.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	 Shawn Guo <shawnguo@kernel.org>
Subject: Re: [PATCH net-next 4/6] net: stmmac: rk: use stmmac_set_tx_clk_gmii()
Date: Thu, 14 Sep 2023 18:22:33 +0300	[thread overview]
Message-ID: <rene2x562lqsknmwpaxpu337mhl4bgynct6vcyryebvem2umso@2pjocnxluxgg> (raw)
In-Reply-To: <ZQMgtXSTsNoZohnx@shell.armlinux.org.uk>

On Thu, Sep 14, 2023 at 04:03:17PM +0100, Russell King (Oracle) wrote:
> On Thu, Sep 14, 2023 at 05:37:13PM +0300, Serge Semin wrote:
> > On Thu, Sep 14, 2023 at 02:51:35PM +0100, Russell King (Oracle) wrote:
> > > Use stmmac_set_tx_clk_gmii().
> > > 
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > > ---
> > >  .../net/ethernet/stmicro/stmmac/dwmac-rk.c    | 60 +++++--------------
> > >  1 file changed, 16 insertions(+), 44 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> > > index d920a50dd16c..5731a73466eb 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> > > @@ -1081,28 +1081,14 @@ static void rk3568_set_gmac_speed(struct rk_priv_data *bsp_priv, int speed)
> > >  {
> > >  	struct clk *clk_mac_speed = bsp_priv->clks[RK_CLK_MAC_SPEED].clk;
> > >  	struct device *dev = &bsp_priv->pdev->dev;
> > > -	unsigned long rate;
> > > -	int ret;
> > > -
> > > -	switch (speed) {
> > > -	case 10:
> > > -		rate = 2500000;
> > > -		break;
> > > -	case 100:
> > > -		rate = 25000000;
> > > -		break;
> > > -	case 1000:
> > > -		rate = 125000000;
> > > -		break;
> > > -	default:
> > > -		dev_err(dev, "unknown speed value for GMAC speed=%d", speed);
> > > -		return;
> > > -	}
> > > -
> > > -	ret = clk_set_rate(clk_mac_speed, rate);
> > > -	if (ret)
> > > -		dev_err(dev, "%s: set clk_mac_speed rate %ld failed %d\n",
> > > -			__func__, rate, ret);
> > > +	int err;
> > > +
> > > +	err = stmmac_set_tx_clk_gmii(clk_mac_speed, speed);
> > > +	if (err == -ENOTSUPP)
> > 
> > > +		dev_err(dev, "invalid speed %uMbps\n", speed);
> > > +	else if (err)
> > > +		dev_err(dev, "failed to set tx rate for speed %uMbps: %pe\n",
> > 
> > These type specifiers should have been '%d' since the speed variable
> > is of the signed integer type here.
> 

> Okay, having re-reviewed the changes, I'm changing them _all_ back to
> be %d, because that is the _right_ thing. It is *not* unsigned, even
> if fix_mac_speed() thinks that it is. It isn't. It's signed, and it's
> stmmac bollocks implicitly casting it to unsigned - and that is
> _wrong_.

Yes, stmmac is wrong in casting it to the unsigned type, but even
seeing the original type is intended to be signed doesn't mean the
qualifier should be fixed separately from the variables type and
function prototypes. It will cause even more confusion. IMO the best
way would be to fix the plat_stmmacenet_data->fix_mac_speed()
prototype and the respective methods in the glue drivers. But it would
be too bulky and most likely out of your interest to be done. So I
would still have the variables type and the format qualifier type
matching here and in the rest of the drivers especially seeing the
original code in the imx, starfive, rk, QoS Eth LLDDs sticks to the
convention described by me.

-Serge(y)

> 
> So, on that point, my original submission was more correct than this
> one, and you led me astray.
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!