On Fri, 10 Mar 2023 14:34:07 +0100 Michael Walle <michael@xxxxxxxx> wrote: > >> > There is a slight inconvenience caused by the fact that there are > >> > already PHY drivers using PHY timestamping, and those may have been > >> > introduced into deployments with PHY timestamping. We cannot change the > >> > default behavior for those either. There are 5 such PHY drivers today > >> > (I've grepped for mii_timestamper in drivers/net/phy). > >> > > >> > I would suggest that the kernel implements a short whitelist of 5 > >> > entries containing PHY driver names, which are compared against > >> > netdev->phydev->drv->name (with the appropriate NULL pointer checks). > >> > Matches will default to PHY timestamping. Otherwise, the new default > >> > will be to keep the behavior as if PHY timestamping doesn't exist > >> > (MAC still provides the timestamps), and the user needs to select the > >> > PHY as the timestamping source explicitly. > >> > > >> > Thoughts? > >> > >> While I agree in principle (I have suggested to make MAC timestamping > >> the default before), I see a problem with the recent LAN8814 PHY > >> timestamping support, which will likely be released with 6.3. That > >> would now switch the timestamping to PHY timestamping for our board > >> (arch/arm/boot/dts/lan966x-kontron-kswitch-d10-mmt-8g.dts). I could > >> argue that is a regression for our board iff NETWORK_PHY_TIMESTAMPING > >> is enabled. Honestly, I don't know how to proceed here and haven't > >> tried to replicate the regression due to limited time. Assuming, > >> that I can show it is a regression, what would be the solution then, > >> reverting the commit? Horatiu, any ideas? Adding this whitelist will add some PHY driver specific name in the phy API core. Will it be accepted? Is it not better to add a "legacy_default_timestamping" boolean in the phy_device struct and set it for these 5 PHY drivers? Then move on the default behavior to MAC default timestamping on the otehr cases. > >> I digress from the original problem a bit. But if there would be such > >> a whitelist, I'd propose that it won't contain the lan8814 driver. > > > > I don't have anything against having a whitelist the PHY driver names. > > Yeah, but my problem right now is, that if this discussion won't find > any good solution, the lan8814 phy timestamping will find it's way > into an official kernel and then it is really hard to undo things. Yes and we need to find a solution as the issue will raise at each new PHY PTP support. Köry
