netdev - Re: Ethernet not working on a different SoC with same eth HW

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, 4 Nov 2016 14:51:47 +0100
From:   Mason <slash.tmp@...e.fr>
To:     Mans Rullgard <mans@...sr.com>
Cc:     netdev <netdev@...r.kernel.org>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Timur Tabi <timur@...eaurora.org>,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        Zefir Kurtisi <zefir.kurtisi@...atec.com>,
        Martin Blumenstingl <martin.blumenstingl@...il.com>,
        Uwe Kleine-Konig <u.kleine-koenig@...gutronix.de>,
        Daniel Mack <zonque@...il.com>,
        Sebastian Frias <sf84@...oste.net>
Subject: Re: Ethernet not working on a different SoC with same eth HW

On 04/11/2016 14:40, Måns Rullgård wrote:

> Mason <slash.tmp@...e.fr> writes:
> 
>> On 31/10/2016 17:28, Mason wrote:
>>
>>> On 31/10/2016 16:53, Andrew Lunn wrote:
>>>
>>>>> I'll add a log for the request_irq call.
>>>>
>>>> And take a look at /proc/interrupts
>>>
>>> You're right, there does seem to be something wrong with the interrupts.
>>
>> Having fixed that, I'm still unable to ping a box on the same
>> ethernet segment... Still investigating.
>>
>> I think I may have spotted a potential issue in the Atheros driver.
>>
>> 	if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||
>> 	    phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
>> 		ret = at803x_enable_rx_delay(phydev);
>> 		if (ret < 0)
>> 			return ret;
>> 	}
>>
>> Looking at this code, one might believe that "rgmii rx clock delay"
>> is only enabled when the user requests it (through DT).
>>
>> http://www.redeszone.net/app/uploads/2014/04/AR8035.pdf
>> cf. PDF page 48
>>
>> *However* this bit is set to 1 at reset (both HW and SW resets).
>> Thus, "rgmii rx clock delay" is always enabled, whether the user
>> requests it or not.
>>
>> Could someone knowledgeable comment on the expected behavior of
>> enabling rgmii rx (and tx) clock delay?
> 
> Clock delay is sometimes (depending on PCB layout) required to achieve
> the correct timing between clock and data signals.  The delay can be
> applied at the MAC or the PHY.  I'd start by finding out what the PCB
> design expects or check the signals with a fast oscilloscope if you have
> one.

Considering the ethernet DT bindings:

https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ethernet.txt

Specifically, phy-mode values "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid".

Assuming that "rxid" (rx internal delay) and "rx clock delay" are
in fact the same concept with different names, do you agree that
it would be unexpected for "rgmii rx clock delay" to be enabled
when a DTB specifies "rgmii" or "rgmii-txid" ?

Regards.