lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 08 Dec 2015 15:13:10 +0100
From: (Krzysztof HaƂasa)
To:	Tim Harvey <>
Cc:	netdev <>
Subject: Re: [PATCH] I.MX6: Fix Ethernet PHY mode on Ventana boards

Tim Harvey <> 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) &

                if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
                        mscr |= (MII_88E1121_PHY_MSCR_RX_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
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
More majordomo info at

Powered by blists - more mailing lists