netdev - RE: [PATCH net-next v2 3/4] Documentation: net: phy: Add blurb about RGMII

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: <063D6719AE5E284EB5DD2968C1650D6DB023015E@AcuExch.aculab.com>
Date:   Wed, 30 Nov 2016 12:32:04 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Florian Fainelli' <f.fainelli@...il.com>,
        Timur Tabi <timur@...eaurora.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "sf84@...oste.net" <sf84@...oste.net>,
        "martin.blumenstingl@...glemail.com" 
        <martin.blumenstingl@...glemail.com>,
        "mans@...sr.com" <mans@...sr.com>,
        "alexandre.torgue@...com" <alexandre.torgue@...com>,
        "peppe.cavallaro@...com" <peppe.cavallaro@...com>,
        "jbrunet@...libre.com" <jbrunet@...libre.com>
Subject: RE: [PATCH net-next v2 3/4] Documentation: net: phy: Add blurb
 about RGMII

From: Florian Fainelli
> Sent: 27 November 2016 23:03
> Le 27/11/2016  14:24, Timur Tabi a crit :
> >> + * PHY device drivers in PHYLIB being reusable by nature, being able to
> >> +   configure correctly a specified delay enables more designs with
> >> similar delay
> >> +   requirements to be operate correctly
> >
> > Ok, this one I don't know how to fix.  I'm not really sure what you're
> > trying to say.
> 
> What I am trying to say is that once a PHY driver properly configures a
> delay that you have specified, there is no reason why this is not
> applicable to other platforms using this same PHY driver.

As has been stated earlier it can depend on the track lengths on the
board itself.
(Although 1ns is about 1 foot - so track delays of that length are unlikely.)

> >> +Common problems with RGMII delay mismatch
> >> +
> >> + When there is a RGMII delay mismatch between the Ethernet MAC and
> >> the PHY, this
> >> + will most likely result in the clock and data line sampling to
> >> capture unstable
> >
> > I'm not sure what "sampling to capture unstable" is supposed to mean.
> 
> When the PHY devices takes a "snapshot" of the state of the data lines,
> after a clock edge, if the delay is improperly configured, these data
> lines are going to still be floating, or show some kind of
> capacitance/inductance effect, so the logical level which is going to be
> read may be incorrect.

No, the problem is that the data lines are being changed at much the same time
as the clock.
Quite possibly on both the rising and falling edges of the clock.

The actual latching of the data requires the data to be stable for the 'setup'
and 'hold' times of the latch (ie before and after the clock edge).
If the data and clock change at the same time it will be indeterminate whether
the old or new data is latched (the latch output might even oscillate).
The delay is there to ensure that the data isn't changing at the same time as
it is sampled.

At lower speed I suspect that the data only changes on one clock edge and is
sampled on the other.
(FWIW the latest DDR has an additional change in the data half way between
the clock edges!)

	David