On Thu, Jan 14, 2021 at 05:31:11PM +0000, Russell King - ARM Linux admin wrote: > On Thu, Jan 14, 2021 at 09:27:12AM -0800, Richard Cochran wrote: > > Thanks for the reminder. We ended up with having to review the MAC > > drivers that support phydev. > > > > > > https://lore.kernel.org/netdev/20200730194427.ge1...@shell.armlinux.org.uk/ > > > > There is at least the FEC that supports phydev. I have a board that > > combines the FEC with the dp83640 PHYTER, and your patch would break > > this setup. (In the case of this HW combination, the PHYTER is > > superior in every way.) > > > > Another combination that I have seen twice is the TI am335x with its > > cpsw MAC and the PHYTER. Unfortunately I don't have one of these > > boards, but people made them because the cpsw MAC supports time > > stamping in a way that is inadequate. > > > > I *think* the cpsw/phyter combination would work with your patch, but > > only if the users disable CONFIG_TI_CPTS at compile time. > > I think then the only solution is to move the decision how to handle > get_ts_info into each MAC driver and get rid of: > > if (phy_has_tsinfo(phydev)) > return phy_ts_info(phydev, info); > > in __ethtool_get_ts_info().
Thinking about this more, that is an impossible task - there's no obvious information around to suggest which ethernet drivers could possibly be attached to a phylib PHY that supports PTP. So, I think the only way to prevent a regression with the code as it is today is that we _never_ support PTP on Marvell PHYs - because doing so _will_ break the existing MVPP2 driver's implementation and cause a regression. Right now, there is no option: if a PHY supports PTP, then the only option is to use the PHYs PTP. Which is utterly rediculous. Unless you can see a way around it. Because I can't. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
