Please ensure the "ls /sys/class/net/${WLAN_DEV}/device/ptp" has the right output, it means there is a available PHC/PTP clock for you and the driver patch successfully. You can read the 'dmesg' output for more info if this step is error for you.
Please "specify the PHC" by "-p /dev/ptp0". You can check your output in shell to find 'phc_index', if it is not equal to '-1', this is not your key point for solving problem.
The configuration file we are using is "configs/defaults.cfg", but if you have meet the error for getting timestamps timeout, you can try to increase 'tx_timestamp_timeout' item.
All my tries are successful under hardware timestamps with '-H'.

The IEEE80211 stack does not implement PHC, so we implemented something that works but may not be right. We convert the actual TSF counter into continuous tstamp and then map it to absolute time using debugfs dirtyts. This allows linuxptp to trigger frequency and offset adjustments of the PTP clock without fully implementing PHC. So, we provide a modified linuxptp in our repository.
Due to the above point, we directly pass tstamp to linuxptp and use a helper function port_dirty_ts() to invoke ath9k's debugfs to complete the actual time mapping (which should be implemented by PHC).
ath_off_timer_cb() is used for TDMA experiments, and we haven't completely cleaned up this part.
Because the timestamp for tx is triggered when the packet is sent, and the rx timestamp is triggered after the packet is received, we chose to align them to the end of the tx/rx packet. However, in actual testing, we found that there is an unknown offset in these timestamps still, so we compensated them with -16 and -2 us. These magic numbers are related to the NIC model.
Another inappropriate practice is that we treat us as ns in the driver. This will be taken care of by linuxptp.

Some problems when setup #8

Description