Tim Harvey <thar...@gateworks.com> writes:
> It sounds like your saying this controls whether the phy is in charge
> of delay vs the MAC. I have never needed to set this and haven't found
> where its actually used (in at least 4.3). Is this caused by something
> new in the kernel I haven't seen yet or is it possible you have board
> that has an Ethernet issue?
I think you aren't using the Marvell PHY driver :-)
The existing DTS files work fine with the "default" PHY driver.
It's only the Marvell driver (drivers/net/phy/marvell.c, aka
CONFIG_MARVELL_PHY) which have the issue.
The problem is caused by the following code in m88e1121_config_aneg():
if (phy_interface_is_rgmii(phydev)) {
mscr = phy_read(phydev, MII_88E1121_PHY_MSCR_REG) &
MII_88E1121_PHY_MSCR_DELAY_MASK;
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
mscr |= (MII_88E1121_PHY_MSCR_RX_DELAY |
MII_88E1121_PHY_MSCR_TX_DELAY);
else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
mscr |= MII_88E1121_PHY_MSCR_RX_DELAY;
else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
mscr |= MII_88E1121_PHY_MSCR_TX_DELAY;
err = phy_write(phydev, MII_88E1121_PHY_MSCR_REG, mscr);
if (err < 0)
return err;
}
mscr initially holds the correct value (one with RX_DELAY and TX_DELAY
bits set). Since the _*ID are not specified, these bits are reset and
(now incorrect) value is written back to the register.
OTOH the generic PHY driver knows nothing about the MSCR and thus
doesn't "corrupt" it.
The whole -ID thing is about signal trace lengths (on PCB), where the
non-ID setup requires special, longer traces for certain signals to
compensate for propagation times etc. The -ID version does it internally
(when enabled) and the PCB layout can be a bit simpler.
To be honest I only checked it on a single GW5400 rev. C, but I'd expect
it to be exactly the same across all GW5[234]*. Can test on GW5[23] if
there is any doubt (in few days I guess).
This issue doesn't show itself on Yocto and OpenWrt, because they
apparently don't enable marvell PHY driver. Fedora 23 does and it
doesn't work (this probably means it could be worth it to push it to
stable).
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
