Hello everyone,

I'm sorry to intervene late in this discussion, but since it looks like
the discussion is converging towards the creation of a new API (though
NDOs internally, and through netlink for userspace), I'd like to add a
small other use-case to consider. Of course, this can be addressed
later on.

On Fri, 10 Mar 2023 13:35:33 +0200
Vladimir Oltean [off-list ref] wrote:

On Fri, Mar 10, 2023 at 11:48:52AM +0100, Köry Maincent wrote:

quoted

quoted

From previous discussions, I believe that a device tree property
was added in order to prevent perceived performance regressions
when timestamping support is added to a PHY driver, correct?  

Yes, i.e. to select the default and better timestamp on a board.  

Is there a way to unambiguously determine the "better" timestamping
on a board?

I'd like to point out a series sent a while ago :

https://lore.kernel.org/netdev/3a14f417-1ae1-9434-5532-4b3387f25d18@orolia.com/ (local)

Here, the MAC's timestamping unit can be configured in 2 ways, which
boils down to either more accurate timestamps, or better accuracy in
frequency adjustments for the clock.

The need is to be able to change this mode at runtime, as we can change
the clock source for the timestamping unit to a very precise-one,
therefore using the "accurate timestamps mode" working as a
grand-master, or switching to slave mode, where we would sacrifice a
little bit the timestamping precision to get better frequency
precision.

So, we can consider here that not only the MAC's timestamping unit has
a non-fixed precision, but if we go through the route a a new API,
maybe we can also take this case into account, allowing for a bit of
configuration of the timestamping unit from userspace? 

Is it plausible that over time, when PTP timestamping matures and,
for example, MDIO devices get support for PTP_SYS_OFFSET_EXTENDED
(an attempt was here: https://lkml.org/lkml/2019/8/16/638), the
relationship between PTP clock qualities changes, and so does the
preference change?

I'm not exactly familiar with PTP_SYS_OFFSET_EXTENDED, but it looks a
bit similar in purpose to the above-mentionned use-case.

Thanks,

Maxime