On Thu, Jan 14, 2021 at 10:38:00PM +0000, Russell King - ARM Linux admin wrote:
> 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. The situation isn't as bad as it seems. For one thing, mvpp2 incorrectly selects NETWORK_PHY_TIMESTAMPING. It really shouldn't. I'm submitting a fix soon. As long as the new PHY driver (or at least the PTP bit) depends on NETWORK_PHY_TIMESTAMPING, then that allows users who _really_ want that to enable the option at compile time. This option adds extra checks into the networking hot path, and almost everyone should avoid enabling it. > 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. I still think the original and best method is to hide the two (and with your new driver, three) esoteric PHY time stamping drivers behind a Kconfig option, and structure the code to favor PHY devices. The idea to favor the MACs, from back in July, doesn't really change the fundamental limitations that - MAC and PHY time stamping cannot work simultaneously, and - Users of PHY devices (representing a tiny minority) must enable the otherwise uninteresting NETWORK_PHY_TIMESTAMPING option at compile time. Thanks, Richard
