daniel-p-carvalho opened a new pull request, #3800: URL: https://github.com/apache/nuttx-apps/pull/3800
## Summary Depends on apache/nuttx#20346. Follow-up to the discussion in #3791: switches `ptpd` from detecting hardware TX timestamp support by trial and error to querying it once at startup, and turns a genuine runtime failure into a visible fault instead of a silent mode switch. - `ptp_initialize_state()` queries the new `SIOCGIFTSCAPS` ioctl once for the configured interface. If `NETDEV_TX_STAMP` is not reported, hardware TX timestamping is not attempted at all, avoiding the previous three-failure probing sequence. - Removed `hwts_tx_failures`, `PTP_HWTS_TX_MAX_FAILURES` and `hwts_tx_disabled`. Hardware TX timestamp use (`state->hwts_tx`) is now a fixed capability read once, not a runtime state machine. - A genuine `ptp_get_tx_timestamp()` timeout on an interface that already reported the capability is now logged with `ptperr` (was `ptpwarn`) and marks `state->hwts_tx_failed`, which the daemon reports through the existing `clock_source_valid` field in `struct ptpd_status_s` while the failure persists - reusing the daemon's existing general health indicator instead of adding a new field, the same way `linuxptp`/`ptp4l` reuses its port state machine (`FAULTY`) instead of a purpose-built flag. `hwts_tx` itself is never disabled by a runtime failure; the daemon keeps attempting hardware timestamps and clears the fault on the next success. ## Test plan - [x] Clean build of an STM32H7 board with the corresponding `nuttx` change (#20346) applied. - [x] `ptpd -H` on real hardware against a physical PTP Grandmaster: confirmed via device log that hardware TX timestamp mode is active from the first packet, with none of the previous timeout/fallback warnings during startup. - [x] 10-minute soak against the Grandmaster: 0 ping failures, `clock_source_valid` stayed true throughout, offset/path delay stable. -- 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]
