On Sun, Jun 23, 2019 at 2:13 AM Sudarsana Reddy Kalluru <skall...@marvell.com> wrote: > > Thanks for uncovering this issue, and the fix. > With the proposed fix, if HW latches the timestamp after 3 iterations then it > would lead to erroneous PTP functionality. When driver receives the next PTP > packet, driver sees that timestamp is available in the register and would > assign this value (which corresponds to last/skipped ptp packet) to the PTP > packet. In general, FW takes around 1ms to 100ms to perform the timestamp and > may take more. Hence the promising solution for this issue would be to wait > for timestamp for particular period of time. If Tx timestamp is not available > for a pre-determined max period, then declare it as an error scenario and > terminate the thread. > > Just for the reference, similar fix was added for Marvell qede driver > recently. Patch details are, > 9adebac37e7d: (qede: Handle infinite driver spinning for Tx timestamp.) > https://www.spinics.net/lists/netdev/msg572838.html >
Thanks a lot for the quick review and good suggestion Sudarsana! I'll rework the fix based on your reference, and resubmit. Cheers, Guilherme
