On Tue, Jun 30, 2020 at 10:13:08PM +0000, René van Dorst wrote:
> Hi Russel and Sean,
>
> Quoting Russell King - ARM Linux admin <li...@armlinux.org.uk>:
>
> > On Tue, Jun 30, 2020 at 11:15:42AM +0100, Russell King wrote:
> > > 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 <rmk+ker...@armlinux.org.uk>
> > > ---
> > > 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!
