linux-kernel - Re: [PATCH] ARM: mach-imx6q: add ksz9131rn_phy

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: <e8ab2b1953dfd27fa38a15b2a3481584c7b53545.camel@toradex.com>
Date:   Fri, 6 Mar 2020 12:16:49 +0000
From:   Philippe Schenker <philippe.schenker@...adex.com>
To:     "o.rempel@...gutronix.de" <o.rempel@...gutronix.de>,
        "a.fatoum@...gutronix.de" <a.fatoum@...gutronix.de>,
        "andrew@...n.ch" <andrew@...n.ch>
CC:     "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        "linux-imx@....com" <linux-imx@....com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "allison@...utok.net" <allison@...utok.net>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "kstewart@...uxfoundation.org" <kstewart@...uxfoundation.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>
Subject: Re: [PATCH] ARM: mach-imx6q: add ksz9131rn_phy_fixup

On Fri, 2020-03-06 at 12:14 +0100, Ahmad Fatoum wrote:
> Hello Philippe,
> 
> On 3/6/20 10:46 AM, Philippe Schenker wrote:
> > Hi Andrew and Ahmad, thanks for your comments. I totally forgot
> > about
> > those more specific phy-modes. But just because none of our driver
> > supports that. Either the i.MX6 fec-driver as well as the micrel.c
> > PHY
> > driver supports this tags.
> > What do you guys suggest then how I should implement that skew
> > stuff?
> 
> I think implementing them in the Micrel driver would make sense.
> When more specific skews are supplied, these are used.
> If not, the rgmii_[tx]?id applies the appropriate timings for length
> matched
> lines. Device trees matching your use case will then only have to
> specify
> rgmii-txid. 
> 
> > The problem is that i.MX6 has an asynchronic skew of -100 to 900ps
> > only
> > enabling the PHY-delay on TXC and RXC is not in all cases within the
> > RGMII timing specs. That's why I implemented this 'weird' numbers.
> 
> I am not too well-versed with this. What's an asynchronic skew?
> A non-deterministic internal delay..? So, you try to be as accurate as
> possible, so the skew is within the acceptable margin?

Asynchronic was a term I introduced because in RGMII spec, TXC of a MAC
should have -500 to 500ps skew. However the i.MX6 has "asynchronic" -100
to 900ps.

I did a worst-case study of those timing values. If I only enable the
2ns delay on the KSZ9131 PHY this is resulting in a T_setup_T of 1.9-
2.4ns (min-max). Under the assumption that tcyc (cycle time of the
clock) has min-max of 7.2-8.8ns this results in T_hold_T values of min-
max 0.7-2.5ns. The 0.7ns should be at least 1ns according to spec.

If I fine tune these values with the other registers I can "middle-out"
the clock-edges in relation to data signals and therefore I get all
values to be within RGMII timing specs.
> 
> Cheers
> Ahmad
> 
> 
> > Philippe
> >