On Tue, Oct 29, 2024 at 01:15:52PM +0100, Andrew Lunn wrote:
> > +#define GMAC_TX_RATE_125M 125000000 /* 125MHz */
> > +#define GMAC_TX_RATE_25M 25000000 /* 25MHz */
> > +#define GMAC_TX_RATE_2M5 2500000 /* 2.5MHz */
>
> With the swap to the new helper, i think 25M and 2M5 are no longer
> needed.
>
Sure, I will fix it in v5.
> > +static int s32_gmac_init(struct platform_device *pdev, void *priv)
> > +{
> > + struct s32_priv_data *gmac = priv;
> > + int ret;
> > +
> > + ret = clk_set_rate(gmac->tx_clk, GMAC_TX_RATE_125M);
> > + if (!ret)
> > + ret = clk_prepare_enable(gmac->tx_clk);
> > +
> > + if (ret) {
> > + dev_err(&pdev->dev, "Can't set tx clock\n");
> > + return ret;
> > + }
> > +
> > + ret = clk_prepare_enable(gmac->rx_clk);
> > + if (ret)
> > + dev_dbg(&pdev->dev, "Can't set rx, clock source is disabled.\n");
> > + else
> > + gmac->rx_clk_enabled = true;
>
> Why would this fail? And if it does fail, why is it not fatal? Maybe a
> comment here.
>
> > +static void s32_fix_mac_speed(void *priv, unsigned int speed, unsigned int mode)
> > +{
> > + struct s32_priv_data *gmac = priv;
> > + long tx_clk_rate;
> > + int ret;
> > +
> > + if (!gmac->rx_clk_enabled) {
> > + ret = clk_prepare_enable(gmac->rx_clk);
> > + if (ret) {
> > + dev_err(gmac->dev, "Can't set rx clock\n");
>
> dev_err(), so is failing now fatal, but since this is a void function,
> you cannot report the error up the call stack?
>
I did a homework and checked the issue which was fixed by that 'lazy' rx
clock enable procedure and got conslusion it is not needed anymore, as I
was not able to reproduce the issue on the same board but with newer
kernel version (6.6.32 versus 5.15.73).
So I will simplify rx clock management in v5.
BR.
/Jan
