On Thu. 5 Oct. 2023 at 16:28, Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote: > On 04.10.2023 21:55:41, Vincent Mailhol wrote: (...) > > If I understand correctly, you only use the hardware timestamp for the > > napi but you do not report it to the userland. > > ACK > > > Not a criticism of this series, but it seems to me that it would be > > easy to add one follow-up patch that would populate > > skb_shared_hwtstamps->hwtstamp and update ethtool_ops->get_ts_info in > > order to report those hardware timestamps to the user. > > Yes. I have proof-of-concept patches for it laying around, but I want to > get this mainline first. One limitation of the hardware is that the > timer is only 16 bits wide and runs on CAN clock, which means a maximum > of 1MHz. This causes the timer to overflow every 64ms, which in turn > requires a worker every 30ms or so. ACK. > For this reason, I want hardware TS > to be configurable and this is not yet implemented. Also $CUSTOMER > doesn't need HW timestamps :) Actually, this is already available in the kernel. You just need to implement the SIOCSHWTSTAMP and SIOCGHWTSTAMP ioctl in net_device_ops->ndo_eth_ioctl(). More details in: https://git.kernel.org/torvalds/c/90f942c5a6d7 The caveat is in the userland: the can-utils currently do not follow the conventions. It does not send those ioctls and instead expects hardware timestamps to be unconditionally always on. But at least, it should work with tcpdump or any other generic packet capture utilities which follow the kernel conventions. (...)
