[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161104151744.GG3600@lunn.ch>
Date: Fri, 4 Nov 2016 16:17:44 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Måns Rullgård <mans@...sr.com>
Cc: Mason <slash.tmp@...e.fr>, 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>,
Sebastian Frias <sf84@...oste.net>
Subject: Re: Ethernet not working on a different SoC with same eth HW
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.
> 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.
> There is also no way to specify the amount of delay required even though
> many devices support more than one value.
Those PHYs that which support variable delays add there own device
tree properties. See for example Micrel KSZ9021/KSZ9031 Gigabit Ethernet PHY
Andrew
Powered by blists - more mailing lists