On 11/04/2016 08:22 AM, Måns Rullgård wrote: > Andrew Lunn <and...@lunn.ch> writes: > >> On Fri, Nov 04, 2016 at 03:05:00PM +0000, Måns Rullgård wrote: >>> Andrew Lunn <and...@lunn.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... -- Florian
