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]
Message-ID: <581C94C9.5080503@laposte.net>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ