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]

Message-ID: <yw1xwpgji3rd.fsf@unicorn.mansr.com>
Date:   Fri, 04 Nov 2016 16:55:18 +0000
From:   Måns Rullgård <mans@...sr.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, Mason <slash.tmp@...e.fr>,
        netdev <netdev@...r.kernel.org>,
        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

Florian Fainelli <f.fainelli@...il.com> writes:

> On 11/04/2016 08:22 AM, Måns Rullgård wrote:
>> Andrew Lunn <andrew@...n.ch> writes:
>> 
>>> On Fri, Nov 04, 2016 at 03:05:00PM +0000, Måns Rullgård wrote:
>>>> Andrew Lunn <andrew@...n.ch> writes:
>>>>
>>>>>>> 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.
>>>>>>
>>>>>> Does the internal delay here refer to the PHY or the MAC?  It's a
>>>>>> property of the MAC node after all.
>>>>>
>>>>> It is the PHY which applies the delay.
>>>>
>>>> Says who?
>>>
>>> The source code.
>> 
>> There's source code that disagrees with that.  The Broadcom GENET
>> driver, for instance.
>
> Correct, and in the case where the MAC adds the delay while transmitting
> (because it supports that) the expectation is that the PHY would remove
> such a delay internally, conversely, the PHY would introduce a delay
> while transmitting back to the PHY, in order to produce the desired 90
> degrees shift on the RGMII signals, and get reproduce the correct clock
> and data alignment internally.
>
>> 
>>>>  Some MACs can do it too.
>>>
>>> I'm sure they can. But look at the code. Nearly none do, and those
>>> that do are potentially broken.
>> 
>> Those few drivers that do anything differently based on these values
>> enable clock delay in the MAC.  That's why I wrote the NB8800 driver the
>> way I did.
>> 
>
> I don't really what is wrong with the nb8800 driver at the moment, so
> maybe this is just a configuration issue with the Atheros PHY driver,
> it's not like it has not given people headache judging by the recent
> discussions...

We don't even know if the problems Mason is having are caused by
incorrect clock skew in the first place.  I'd suggest not patching
anything at all until he gets it working.

-- 
Måns Rullgård