On Tue, Jun 30, 2020 at 10:13:08PM +0000, René van Dorst wrote:

Hi Russel and Sean,

Quoting Russell King - ARM Linux admin [off-list ref]:

quoted

On Tue, Jun 30, 2020 at 11:15:42AM +0100, Russell King wrote:

quoted

The SGMII PCS PHY needs to be updated with the link configuration in
the mac_link_up() call rather than in mac_config().  However,
mtk_sgmii_setup_mode_force() programs the SGMII block during
mac_config() when using 802.3z interface modes with the link
configuration.

Split that functionality from mtk_sgmii_setup_mode_force(), moving it
to a new mtk_sgmii_link_up() function, and call it from mac_link_up().

This does not look correct to me: 802.3z modes operate at a fixed
speed.  The contents of mtk_sgmii_link_up() look more appropriate for
SGMII mode, but the original code definitely did not call
mtk_sgmii_setup_mode_force() for SGMII mode but only 802.3z mode.

Signed-off-by: Russell King <redacted>
---
René, can you assist with this patch please - I really think there are
problems with the existing code.  You call mtk_sgmii_setup_mode_force()
in a block which is conditionalised as:

	if (state->interface == PHY_INTERFACE_MODE_SGMII ||
	    phy_interface_mode_is_8023z(state->interface)) {
...
		if (state->interface != PHY_INTERFACE_MODE_SGMII)
			err = mtk_sgmii_setup_mode_force(eth->sgmii, sid,
							 state);

Hence, mtk_sgmii_setup_mode_force() is only called for 1000BASE-X and
2500BASE-X, which do not support anything but their native speeds.
Yet, mtk_sgmii_setup_mode_force() tries to program the SGMII for 10M
and 100M.

Note that this patch is more about moving uses of state->{speed,duplex}
into mac_link_up(), rather than fixing this problem, but I don't think
the addition in mtk_mac_link_up(), nor mtk_sgmii_link_up() is of any
use.

My Coccinelle script just found this use of state->{speed,duplex} still
remaining:

                        if (MTK_HAS_CAPS(mac->hw->soc->caps,
                                         MTK_TRGMII_MT7621_CLK)) {
...
                        } else {
                                if (state->interface !=
                                    PHY_INTERFACE_MODE_TRGMII)
                                        mtk_gmac0_rgmii_adjust(mac->hw,
                                                               state->speed);

which also needs to be eliminated.  Can that also be moved to
mtk_mac_link_up()?

I know, you have pointed that out before. But I don't know how to fix
mtk_gmac0_rgmii_adjust(). This function changes the PLL of the MAC. But
without documentation I am not sure what all the bits are used for.

I'd forgotten...

Begin April I had a conversation with Sean about this. I also explained what
the issue was. AFAIK he was going to take care of this issue.

Sean did you had time to resolve this issue?

Well, I think the code as it stands is quite broken.

If we start a bit earlier in mtk_mac_config(), we have this:

        if (!MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628) &&
            mac->interface != state->interface) {

which prevents us entering this block unless the interface mode has
changed and we are not MT7628.  This block of code includes the two
calls to mtk_gmac0_rgmii_adjust(), which are dependent on
state->speed.

Since mac->interface starts off as PHY_INTERFACE_MODE_NA, the first
time we head into mtk_mac_config(), the interface mode will be
different, and we will enter this block of code, maybe calling down
into mtk_gmac0_rgmii_adjust() if appropriate.

The first call will be via phylink_start(), which will call it with
the initial configuration - the link will be down, and state->speed
will be SPEED_UNKNOWN.  So, the various tests inside
mtk_gmac0_rgmii_adjust() for speed == SPEED_1000 will all be false,
meaning it'll program it as if for 10M or 100M speeds.

When the link comes up, yes, mtk_mac_config() will be called again
with the link parameters, but state->interface will now match
mac->interface - so the block of code containing the call to
mtk_gmac0_rgmii_adjust() will not be entered, and so none of that
code gets executed when the link comes up/down.

Now, if I dig out object 8ddbb8dcf032 from the git repository, which
was the state of the file immedately prior to the phylink conversion,
I find:

static void mtk_phy_link_adjust(struct net_device *dev)
{

This is the function that phylib would call when the link comes up
or down.  It tests for MTK_RESETTING, starts preparing a value for
mcr, and then:

        if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_GMAC1_TRGMII) && !mac->id) {
                if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_TRGMII_MT7621_CLK)) {
                        if (mt7621_gmac0_rgmii_adjust(mac->hw,
                                                      dev->phydev->interface))
                                return;
                } else {
                        if (!mac->trgmii)
                                mtk_gmac0_rgmii_adjust(mac->hw,
                                                       dev->phydev->speed);
                }
        }

It then finishes creating a value for mcr, before writing it to the
register, and printing the link status to the kernel log.

Hence, mtk_gmac0_rgmii_adjust() would've been called every time there's
a change of link state, and is expected to be passed the current speed.

There seems to be a difference in behaviour between the pre-phylink and
post-phylink drivers, and I think moving mtk_gmac0_rgmii_adjust() into
mtk_mac_link_up() would be a definite improvement, possibly even a
regression fix.

However, it would be reasonable to assume that there should be reports
that mtk_eth_soc doesn't work if this were the case.  So... odd.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!