[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+h21hr2Mx5MpWz-ait_T1eR8GBKmH=1jVfVcsZ-Py7Hcov0ng@mail.gmail.com>
Date: Tue, 24 Mar 2020 16:13:40 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: "David S. Miller" <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Antoine Tenart <antoine.tenart@...tlin.com>
Subject: Re: [PATCH net-next] net: phy: mscc: consolidate a common RGMII delay implementation
On Tue, 24 Mar 2020 at 15:40, Andrew Lunn <andrew@...n.ch> wrote:
>
> On Tue, Mar 24, 2020 at 02:48:37PM +0200, Vladimir Oltean wrote:
> > From: Vladimir Oltean <vladimir.oltean@....com>
> >
> > It looks like the VSC8584 PHY driver is rolling its own RGMII delay
> > configuration code, despite the fact that the logic is mostly the same.
> >
> > In fact only the register layout and position for the RGMII controls has
> > changed. So we need to adapt and parameterize the PHY-dependent bit
> > fields when calling the new generic function.
>
> Nice.
>
> > -static void vsc8584_rgmii_set_skews(struct phy_device *phydev)
> > -{
> > - u32 skew_rx, skew_tx;
> > -
> > - /* We first set the Rx and Tx skews to their default value in h/w
> > - * (0.2 ns).
> > - */
>
> I like seeing this comment. It makes it clear that
> PHY_INTERFACE_MODE_RGMII does not actually mean 0ns, but 0.2ns. It
> also makes it clear that if PHY_INTERFACE_MODE_RGMII_ID,
> PHY_INTERFACE_MODE_RGMII_RXID or PHY_INTERFACE_MODE_RGMII_TXID is not
> given, the delay is set to something. We have had PHY drivers which
> get this wrong and leave the bootloader/strapping value in place.
>
> So if you can keep the comment in some form, that would be good.
>
> Thanks
> Andrew
I find the comments fairly redundant since the code that does that is
already explicit, but anyway I'll send a v2 for the 0.2 ns thing.
Thanks,
-Vladimir
Powered by blists - more mailing lists