[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yw1xpombjnfn.fsf@unicorn.mansr.com>
Date: Fri, 04 Nov 2016 15:05:00 +0000
From: Måns Rullgård <mans@...sr.com>
To: Andrew Lunn <andrew@...n.ch>
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
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? Some MACs can do it too.
> The phy-mode property is in the MAC part of the device tree binding,
> but the delay is not the primary purpose of this property. Its primary
> purpose, RGMII, RMII, SGMII, etc, is applicable to both the MAC and
> the PHY. It probably would of been better to have the delays as a
> separate property, but that is not how it is...
The connection type is obviously the same at both ends, so it doesn't
really matter where that is specified. The delay can be applied at
either end or not at all, and it's anything but clear what the
properties are supposed to mean.
There is also no way to specify the amount of delay required even though
many devices support more than one value.
--
Måns Rullgård
Powered by blists - more mailing lists