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 <vladimir.oltean@xxxxxxx> wrote: > On Fri, Mar 10, 2023 at 11:48:52AM +0100, Köry Maincent wrote: > > > 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@xxxxxxxxxx/ 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
