On 27.07.2022 19:16:27, Vincent Mailhol wrote:
> This series revolves around ethtool and timestamping. Its ultimate
> goal is that the timestamping implementation within socketCAN meets
> the specification of other network drivers in the kernel. This way,
> tcpdump or other tools derived from libpcap can be used to do
> timestamping on CAN devices.
> 
> * Example on a device with hardware timestamp support *
> 
> Before this series:
> | # tcpdump -j adapter_unsynced -i can0
> | tcpdump: WARNING: When trying to set timestamp type
> | 'adapter_unsynced' on can0: That type of time stamp is not supported
> | by that device
> 
> After applying this series, the warning disappears and tcpdump can be
> used to get RX hardware timestamps.
> 
> 
> This series is articulated in three major parts.
> 
> * Part 1: Add TX software timestamps and report the software
>   timestamping capabilities through ethtool.
> 
> All the drivers using can_put_echo_skb() already support TX software
> timestamps. However, the five drivers not using this function (namely
> can327, janz-ican3, slcan, vcan and vxcan) lack such support. Patch 1
> to 4 adds this support.  Finally, patch 5 advertises the timesamping
> capabilities of all drivers which do not support hardware timestamps.
> 
> 
> * Part 2: add TX hardware timestapms
> 
> This part is a single patch. In SocketCAN TX hardware is equal to the
> RX hardware timestamps of the corresponding loopback frame. Reuse the
> TX hardware timestamp to populate the RX hardware timestamp. While the
> need of this feature can be debatable, we implement it here so that
> generic timestamping tools which are agnostic of the specificity of
> SocketCAN can still obtain the value. For example, tcpdump expects for
> both TX and RX hardware timestamps to be supported in order to do:
> | # tcpdump -j adapter_unsynced -i canX
> 
> 
> * Part 3: report the hardware timestamping capabilities and implement
>   the hardware timestamps ioctls.
> 
> The kernel documentation specifies in [1] that, for the drivers which
> support hardware timestamping, SIOCSHWTSTAMP ioctl must be supported
> and that SIOCGHWTSTAMP ioctl should be supported. Currently, none of
> the CAN drivers do so. This is a gap.
> 
> Furthermore, even if not specified, the tools based on libpcap
> (e.g. tcpdump) also expect ethtool_ops::get_ts_info to be implemented.
> 
> This last part first adds some generic implementation of
> net_device_ops::ndo_eth_ioctl and ethtool_ops::get_ts_info which can
> be used by the drivers with hardware timestamping capabilities.
> 
> It then uses those generic functions to add ioctl and reporting
> functionalities to the drivers with hardware timestamping support
> (namely: mcp251xfd, etas_es58x, kvaser_{pciefd,usb}, peak_{canfd,usb})
> 
> 
> [1] Kernel doc: Timestamping, section 3.1 "Hardware Timestamping
> Implementation: Device Drivers"
> Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers
> 
> 
> * Testing *
> 
> I also developed a tool to test all the different timestamps. For
> those who would also like to test it, please have a look at:
> https://lore.kernel.org/linux-can/20220725134345.432367-1-mailhol.vincent@wanadoo.fr/T/

Applied to linux-can-next/master with fixed mscan driver.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |