On Mon, Jun 03, 2019 at 09:24:24AM +0200, Miroslav Lichvar wrote: > On Fri, May 31, 2019 at 07:25:45AM -0700, Richard Cochran wrote: > > A single, external PTP Hardware Clock device may be wired to one or more > > MAC devices, providing the MACs with an input clock. This patch adds > > support for such a hardware architecture by letting the command line PHC > > override the one discovered via the ethtool ioctl. > > Maybe I don't understand what is special about this case, but to me it > feels odd that applications would need to be configured to use the > right PHC.
Yeah, I admit it is a bit hacky. > Applications that automatically enable HW timestamping on > all interfaces would break, right? Not necessarily. The time stamping and PHC APIs are separate, so as long as the MACs are frequency locked to the PHC, it just works. Of course, you need to correct the PHC-to-MAC phase offsets once (using a another helper program). There is now an example of such a PHC in drivers/ptp/ptp_ines.c. > Any chance this could be addressed at the kernel, driver, and/or > device tree? I mean, sure it would be somehow possible to have ethtool/rtnl return an entire clock tree, but that would be a major undertaking, don't you think? For now, this small blemish will cover realistic use cases for the foreseeable future. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
