Re: [PATCH v1 net] net: ethernet: mscc: ocelot: bug fix when writing MAC speed

On Wed, Sep 15, 2021 at 05:29:57PM -0700, Colin Foster wrote:

On Wed, Sep 15, 2021 at 12:25:52PM +0000, Vladimir Oltean wrote:

quoted

On Tue, Sep 14, 2021 at 11:21:02PM -0700, Colin Foster wrote:

quoted

Converting the ocelot driver to use phylink, commit e6e12df625f2, uses mac_speed
in ocelot_phylink_mac_link_up instead of the local variable speed. Stale
references to the old variable were missed, and so were always performing
invalid second writes to the DEV_CLOCK_CFG and ANA_PFC_CFG registers.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/ethernet/mscc/ocelot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
index c581b955efb3..91a31523be8f 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c

@@ -566,11 +566,11 @@ void ocelot_phylink_mac_link_up(struct ocelot *ocelot, int port,
 	/* Take MAC, Port, Phy (intern) and PCS (SGMII/Serdes) clock out of
 	 * reset
 	 */
-	ocelot_port_writel(ocelot_port, DEV_CLOCK_CFG_LINK_SPEED(speed),
+	ocelot_port_writel(ocelot_port, DEV_CLOCK_CFG_LINK_SPEED(mac_speed),
 			   DEV_CLOCK_CFG);

Oh wow, I don't know how this piece did not get deleted. We write twice
to DEV_CLOCK_CFG, once with a good value and once with a bad value.
Please delete the second write entirely.

It seemed odd to me at first, but I looked into the datasheet and saw
that multiple writes to the DEV_CLOCK_CFG register in section 5.2.1
https://ww1.microchip.com/downloads/en/DeviceDoc/VMDS-10491.pdf

11. Set up the switch port to the new mode of operation. Keep the reset bits in CLOCK_CFG set.
12. Release the switch port from reset by clearing the reset bits in CLOCK_CFG.

From that it seems like maybe the routine must be two-fold. First a
write to set up the link speed with:
ocelot_port_rmwl(ocelot_port, DEV_CLOCK_CFG_LINK_SPEED(mac_speed), 
                 DEV_CLOCK_CFG_LINK_SPEED_M, DEV_CLK_CFG);
ocelot_port_writel(ocelot_port, DEV_CLOCK_CFG_LINK_SPEED(mac_speed),
                   DEV_CLK_CFG);

Yes, that cycle is supposed to be completed by ocelot_phylink_mac_link_down
which does put the port in reset, and ocelot_phylink_mac_link_up puts it
back out of it. The third write to DEV_CLOCK_CFG is simply nonsensical.

Of note: I'm currently only using the VSC7512 ports 0-3, which don't
have a PCS and therefore don't have the PCS_RATE_ADAPTATION requirement.

Observation: as long as Alex's original code is correct, then the
PCS_RATE_ADAPTATION quirk is only needed for an _NXP_ PCS. The VSC7514
family uses a Microchip PCS1G block and the code unconditionally changes
the DEV_CLOCK_CFG_LINK_SPEED, so if this is correct, it means that
different PCS blocks have different requirements.