On Sun, May 13, 2018 at 1:29 PM, Andrew Lunn <andrew@xxxxxxx> wrote: > On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote: >> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@xxxxxxx> wrote: >> >> > Hi Chen-Yu >> >> > >> >> > Are these delays the MAC applies? Not the PHY. It would be good to >> >> > make it clear here these are MAC imposed delays. >> >> >> >> Yes these are applied on the MAC side. Being described in the device >> >> tree bindings for the MAC, I thought this was implied to be the case? >> >> Are there known exceptions? >> > >> > There is frequent confusion with this. Most of the time, the PHY does >> > the delay, not the MAC, based on the phy-mode. So the MAC doing it is >> > an exception in itself. >> > >> > Do you actually need these delays for the board you adding support >> > for? Does the PHY not support adding the needed delays? If you don't >> > need the delays, i would not even implement them. >> >> Yes this is already used on the Bananapi M3. This patch merely reformats >> the description and adds a note saying this only applies to RGMII mode. > > Yes, the current code is needed for the Bananapi M3. But you have > another patch which extends the code to support a smaller range. Do > you have a board which actually needs this? If not, i would not add > that new code. IIRC the delay on the PHY side is either 2ns or none. The delay on the MAC side here is an order smaller, likely fine tuning to cope with board design deficiencies. Currently no other board requires this, but this is already part of the binding. The new stuff limits the range for a specific SoC, simply because that is the range supported by the control register. Not implementing, i.e. supporting the whole range from the property, which might get truncated, doesn't make much sense to me. Regards ChenYu -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
