On Fri, 10 Mar 2023 14:34:07 +0100
Michael Walle [off-list ref] wrote:

quoted

quoted

quoted

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.
 

quoted

quoted

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