daniel-p-carvalho commented on code in PR #20148: URL: https://github.com/apache/nuttx/pull/20148#discussion_r4021114228
########## include/nuttx/net/ioctl.h: ########## @@ -161,6 +161,10 @@ #define SIOCGIFVLAN _SIOC(0x0043) /* Get VLAN interface */ #define SIOCSIFVLAN _SIOC(0x0044) /* Set VLAN interface */ +/* PTP Timestamping *********************************************************/ + +#define SIOCG_TX_HW_TIMESTAMP _SIOC(0x0046) /* Get hardware TX timestamp */ Review Comment: No, Linux doesn't have a direct equivalent for any of the three - it exposes each NIC's PTP hardware clock as its own /dev/ptpN character device with a clockid_t, disciplined via the standard POSIX clock_adjtime() syscall rather than a dedicated network ioctl. TX timestamp retrieval similarly goes through SO_TIMESTAMPING + the socket error queue (MSG_ERRQUEUE/SCM_TIMESTAMPING), which NuttX's socket layer doesn't implement (MSG_ERRQUEUE is defined for API compat but unused, and there's a comment in inet_sockif.c noting SO_TIMESTAMPING as future work). While looking into this I found drivers/timers/ptp_clock.c already implements a generic upper-half PTP hardware clock framework matching Linux's /dev/ptpN model closely - PTP_CLOCK_ADJTIME handling ADJ_FREQUENCY/ADJ_OFFSET via struct timex, the dynamic-clockid-to-fd conversion, etc. It has no registered lower-half driver anywhere in the tree yet, and its adjfine/adjphase ops map almost directly onto what this PR already implements in stm32_eth_ptp_adjust()/stm32_eth_ptp_adjphase(). I didn't know about it when I wrote this PR; migrating to it as a lower-half driver looks like the right direction for SIOCS_PTP_ADJFREQ/SIOCS_PTP_ADJPHASE, dropping both in favor of /dev/ptp0. SIOCG_TX_HW_TIMESTAMP is unrelated to that framework though - it's per-packet TX timestamp retrieval, not clock discipline, and there's no equivalent facility in ptp_clock.c for it; the real Linux equivalent there is SO_TIMESTAMPING/MSG_ERRQUEUE, which as noted isn't implemented in NuttX, so I don't see a smaller -scope alternative to keeping that one as a plain ioctl for now. Would you rather I do the /dev/ptp0 migration for ADJFREQ/ADJPHASE in this PR, or land the current ioctls now and follow up separately? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
