netdev - Re: Quirks of the Atheros 8035 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]

Date:   Fri, 14 Jul 2017 23:12:52 +0200
From:   Mason <slash.tmp@...e.fr>
To:     netdev <netdev@...r.kernel.org>,
        Martin Blumenstingl <martin.blumenstingl@...il.com>,
        Grygorii Strashko <grygorii.strashko@...com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Mans Rullgard <mans@...sr.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: Quirks of the Atheros 8035 PHY

Mugunthan's address bounces. Removing it.
Adding Grygorii's address instead.

On 14/07/2017 23:08, Mason wrote:

> Hello,
> 
> I've discussed this subject in the past, but we never reached
> a conclusion, AFAIR.
> 
> The Atheros 8035 GigE PHY has IMO 2 quirks wrt to clock delays.
> 
> https://www.redeszone.net/app/uploads/2014/04/AR8035.pdf
> 
> 
> 1) RX clock delay
> 
> Commit 2e5f9f281ee8369f56d403b4a52942f19b6978f8
> 
> In fact, RX clock delay is *ENABLED* by default at
> reset. So if a board actually required it *disabled*
> then we actually need to set the bit to 0.
> 
> Reference:
> 4.2.25 rgmii rx clock delay control
> 
> 
> 2) TX clock delay
> 
> Commit 1ca6d1b1aef4628ff0fe458135ddb008d134ad8f
> 
> TX clock delay is DISABLED by default, so no surprises
> there... except that it is only DISABLED after *HW reset*.
> 
> After a SW reset, such as that performed in Linux IIUC,
> the PHY retains the value previously set.
> 
> So if a bootloader such a Uboot enabled TX delay, then
> Linux would "inherit" the setting, even if it performs
> a reset. If the PHY setting calls for no TX clock delay,
> the Linux driver would have to actively disable it.
> 
> Reference:
> 4.2.26 rgmii tx clock delay control
> 
> 
> I can (of course) send a patch fixing both issues, but
> what was said last time was that "it's too late to
> fix it now, since the fix risks breaking working
> setups". Is that an accurate paraphrase?
> 
> 
> 3) There's also a RGMII GTX_CLK documented as
> "RGMII transmit clock, 125 MHz digital. Adding a 22 ohm
> damping  resistor is recommended for EMI design near MAC side"
> => Is that TX_CLK?
> There's a 2-bit related field called Gtx_dly_val
> which allows tweaking the delay
> 
> Select the delay of gtx_clk.
> 00: 0.25ns
> 01: 1.3ns
> 10: 2.4ns
> 11: 3.4ns
> (DEFAULT 10b = 2.4 ns, BUT Retain val on SW reset,
> so inherit bootloader value)
> I'm not sure the current DT allows such fine-grained
> tweaking? Should we enhance it?
> 
> 
> 4) There's the whole mess of having clock delays
> supported both by the PHY *AND* the MAC. If both
> add a delay, things won't work as expected.
> What's the recommended approach there?
> 
> 
> Regards.