net: add NETDEV_TX_STAMP capability flag and SIOCGIFTSCAPS query ioctl

[daniel-p-carvalho]

Summary

• Follow-up to the discussion in netutils/ptpd: hardware TX timestamps via MSG_ERRQUEUE and egress latency compensation nuttx-apps#3791.
• ptpd (companion PR netutils/ptpd: query timestamping capabilities via SIOCGIFTSCAPS nuttx-apps#3800) currently detects hardware TX timestamp support by trial and error (three consecutive failures, then a silent switch to software timestamps). The Linux equivalent solves this by having the driver statically declare the capability (SOF_TIMESTAMPING_TX_HARDWARE, read once via ethtool/SIOCETHTOOL); this PR adds the NuttX equivalent.
• NETDEV_TX_STAMP (1 << 4) added to include/nuttx/net/netdev.h, next to the existing NETDEV_RX_STAMP. A driver sets it in d_features to declare that it delivers hardware TX timestamps.
• New SIOCGIFTSCAPS ioctl (net/netdev/netdev_ioctl.c), returning the RX/TX timestamping bits of d_features for a named interface via struct ifreq, following the same pattern already used by SIOCGIFFLAGS.
• STM32H7 Ethernet driver (arch/arm/src/stm32h7/stm32_ethernet.c) declares NETDEV_TX_STAMP when CONFIG_STM32_ETH_TIMESTAMP_TX is enabled, mirroring the existing NETDEV_RX_STAMP declaration right above it.
• STM32F1/F3/F4 Ethernet driver (arch/arm/src/common/stm32/stm32_eth_m3m4_v1.c) declares NETDEV_TX_STAMP the same way.
• Related NuttX Apps Pull Request: ptpd queries this capability once at startup instead of detecting it by trial and error.

Impact

• Is new feature added? Is existing feature changed? YES - new NETDEV_TX_STAMP capability flag and SIOCGIFTSCAPS ioctl; no existing behavior changes for drivers that do not opt in.
• Impact on user (will user need to adapt to change)? NO for existing users; enables netutils/ptpd: query timestamping capabilities via SIOCGIFTSCAPS nuttx-apps#3800 to remove its runtime detection.
• Impact on build (will build process change)? NO.
• Impact on hardware (will arch(s) / board(s) / driver(s) change)? YES - STM32H7 and STM32F1/F3/F4 Ethernet drivers now declare NETDEV_TX_STAMP in d_features when CONFIG_STM32_ETH_TIMESTAMP_TX is set. Both already deliver hardware TX timestamps today; this only makes that capability queryable, it does not change the timestamping behavior itself.
• Impact on documentation (is update required / provided)? NO - NETDEV_TX_STAMP/SIOCGIFTSCAPS follow the exact naming and usage pattern of the existing NETDEV_RX_STAMP/SIOCGIFFLAGS, self-documented by that symmetry.
• Impact on security (any sort of implications)? NO.
• Impact on compatibility (backward/forward/interoperability)? NO.

Testing

I confirm that changes are verified on local setup and works as intended:

• Build Host(s): Linux (Ubuntu), x86_64, GCC (arm-none-eabi-gcc toolchain).
• Target(s): arm, two real boards, both against a physical IEEE 1588 PTP Grandmaster over Ethernet, exercised end-to-end through the companion netutils/ptpd: query timestamping capabilities via SIOCGIFTSCAPS nuttx-apps#3800 change:
  • STM32H7 board (CONFIG_STM32_ETH_TIMESTAMP_TX=y).
  • STM32F1/F3/F4 board (CONFIG_STM32_ETH_TIMESTAMP_TX=y).

Build log (STM32H7 board):

Memory region         Used Size  Region Size  %age Used
            itcm:           0 B        64 KB      0.00%
           flash:      390924 B         2 MB     18.64%
           dtcm1:           0 B        64 KB      0.00%
           dtcm2:           0 B        64 KB      0.00%
            sram:       50104 B       512 KB      9.56%
           sram1:           0 B       128 KB      0.00%
           sram2:           0 B       128 KB      0.00%
           sram3:           0 B        32 KB      0.00%
           sram4:           0 B        64 KB      0.00%
           bbram:           0 B         4 KB      0.00%
CP: nuttx.hex
CP: nuttx.bin

Runtime log, ptpd -s -2 -H -B -P -i eth0 -p /dev/ptp0 status query on the STM32H7 board: SIOCGIFTSCAPS correctly reports NETDEV_TX_STAMP, hardware TX timestamp active from the first packet:

PTPD (PID 8) status:
- clock_source_valid: 1
- last_delta_ns: 539
- drift_ppb: 16265
- path_delay_ns: 9386
- last_received_announce: 1 s ago
- last_received_sync: 1 s ago

Same test on the STM32F1/F3/F4 board (dmesg excerpt, full PTP P2P exchange, hardware TX timestamp used throughout):

ptp_update_local_clock: Local time: 1790260023.503704646, remote time 1790260023.503692546
ptp_update_local_clock: Delta: -2788 ns, adjustment -80060 ns, drift rate -79662 ppb
ptp_record_path_delay: Path delay: 9304 ns (avg: 9312 ns)

10-minute soak against the Grandmaster (STM32H7 board): 0 ping failures over 19 samples at 30s intervals, clock_source_valid stayed 1 throughout, path_delay_ns stable between 9381-9395 ns.

PR verification Self-Check

• This PR introduces only one functional change.
• I have updated all required description fields above.
• My PR adheres to Contributing Guidelines and Documentation (git commit title and message, coding standard, etc).
• My PR is still work in progress (not ready for review).
• My PR is ready for review and can be safely merged into a codebase.

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[xiaoxiang781216]

but show we expose these flags through SIOCETHTOOL

[xiaoxiang781216]

should we return all feature bits