On Wed, Oct 07, 2020 at 12:39:49PM +0200, Kurt Kanzenbach wrote: > On Tue Oct 06 2020, Vladimir Oltean wrote: > > On Tue, Oct 06, 2020 at 03:56:31PM +0200, Kurt Kanzenbach wrote: > >> Yeah, sure. That use case makes sense. What's the problem exactly? > > > > The SO_TIMESTAMPING / SO_TIMESTAMPNS cmsg socket API simply doesn't have > > any sort of identification for a hardware TX timestamp (where it came > > from). > > This is sounds like a problem. Yeah, tell me about it. > For instance the hellcreek switch has actually three ptp hardware > clocks and the time stamping can be configured to use either one of > them. The sja1105 also has a corrected and an uncorrected PTP clock that can take timestamps. Initially I had thought I'd be going to spend some time figuring out multi-PHC support, but now I don't see any practical reason to use the uncorrected PHC for anything. > How would the user space distinguish what time stamp is taken by > which clock? This is not a problem at the moment, because currently > only the synchronized clock is exported to user space. See change log > of this patch. It wouldn't, of course. You'd need to add the plumbing for that. > > So when you'll poll for TX timestamps, you'll receive a TX > > timestamp from the PHY and another one from the switch, and those will > > be in a race with one another, so you won't know which one is which. > > OK. So what happens if the driver will accept to disable hardware > timestamping? Is there anything else that needs to be implemented? Are > there (good) examples? It needs to not call skb_complete_tx_timestamp() and friends. For PHY timestamping, it also needs to invoke the correct methods for RX and for TX, where the PHY timestamping hooks will get called. I don't think that DSA is compatible yet with PHY timestamping, but it is probably a trivial modification. Please read Documentation/networking/timestamping.rst, we try to keep it fairly comprehensive. Thanks, -Vladimir
