netdev - Re: [PATCH] I.MX6: Fix Ethernet PHY mode on Ventana boards

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <m3zixlav0p.fsf@t19.piap.pl>
Date:	Tue, 08 Dec 2015 15:13:10 +0100
From:	khalasa@...p.pl (Krzysztof Hałasa)
To:	Tim Harvey <tharvey@...eworks.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] I.MX6: Fix Ethernet PHY mode on Ventana boards

Tim Harvey <tharvey@...eworks.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html