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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 4 Nov 2016 15:01:45 +0100
From:   Sebastian Frias <sf84@...oste.net>
To:     Andrew Lunn <andrew@...n.ch>, Mason <slash.tmp@...e.fr>
Cc:     Mans Rullgard <mans@...sr.com>, netdev <netdev@...r.kernel.org>,
        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>
Subject: Re: Ethernet not working on a different SoC with same eth HW

On 11/04/2016 02:57 PM, Andrew Lunn wrote:
>> 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" ?
> 
> I agree with you. But fixing it is likely to break boards which
> currently have "rgmii", but actually need the delay in order to work.
> 
> 	  Andrew
> 

I think you are right, if I disable the RX delay on 'drivers/net/phy/at803x.c'
I get RX errors when using the 'drivers/net/ethernet/aurora/nb8800.c' driver,
errors reported in function nb8800_poll()

if (IS_RX_ERROR(rxd->report))
{
   nb8800_rx_error(dev, rxd->report);
}

(this is on the same board Mason is discussing about)

Another thing to note is that 'drivers/net/ethernet/aurora/nb8800.c' is
currently checking PHY_INTERFACE_MODE_RGMII_TXID to add a TX clock output
delay.

Since a PHY, like the 'drivers/net/phy/at803x.c', will setup a TX delay if
phy-connection-type="rgmii-txid" on DT, the code in 'nb8800.c' may be adding
an additional (and possibly unwanted) delay, right?

Actually, I have a patch for 'nb8800.c' to remove the "additional" TX delay,
and I did not see regressions with it. I can post the patch as RFC if
you want.

One more thing, the "tx" and "rx" concepts are in reference to what?
Is "tx" at PHY driver to be matched by "rx" at Ethernet driver?

Best regards,

Sebastian