From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Andrew Lunn <andrew@lunn.ch>,
Pavan Chebbi <pavan.chebbi@broadcom.com>,
Kamil Zaripov <zaripov-kamil@avride.ai>
Cc: netdev@vger.kernel.org, Michael Chan <michael.chan@broadcom.com>,
Andrew Gospodarek <andrew.gospodarek@broadcom.com>
Subject: Re: bnxt_en: Incorrect tx timestamp report
Date: Thu, 20 Mar 2025 16:21:57 +0000 [thread overview]
Message-ID: <37629e9c-0a9f-4e08-921c-efbf7824c371@linux.dev> (raw)
In-Reply-To: <6c63cb1a-ba98-47d8-a06a-e8bacf32f45a@lunn.ch>
On 20/03/2025 14:48, Andrew Lunn wrote:
>> 2. Is there a method available to read the complete 64-bit PHC
>> counter to mitigate the observed problem of 2^48-nanosecond time
>> jumps?
>
> The usual workaround is to read the upper part, the lower part, and
> the upper part again. If you get two different values for the upper
> part, do it all again, until you get consistent values.
>
> Look around other PTP drivers, there is probably code you can
> copy/paste.
This part of the driver is tricky. ASYNC_EVENT_CMPL_EVENT_ID_PHC_UPDATE
reports only 16 bits of 64 bits timestamp, 48-63 range, which doesn't
overlap with anything else. The assumption is that when the driver
processes this event, the register which reports bits of range 0-47 has
already overflowed and holds new value. Unfortunately, there is a time
gap between register overflow and update of MSB of the cached timestamp.
There is no easy way to solve this problem, but we may add additional
check on every read, probably... Not sure, though
next prev parent reply other threads:[~2025-03-20 16:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 14:35 bnxt_en: Incorrect tx timestamp report Kamil Zaripov
2025-03-20 14:48 ` Andrew Lunn
[not found] ` <CAGtf3ibFAidzpFKm1o5zmZF3Neu8MgdXp_n_Wt+mv8M9YZhhug@mail.gmail.com>
2025-03-20 15:14 ` Kamil Zaripov
2025-03-20 16:21 ` Vadim Fedorenko [this message]
2025-03-20 15:56 ` Pavan Chebbi
2025-03-20 16:21 ` Kamil Zaripov
2025-03-20 16:26 ` Vadim Fedorenko
2025-03-20 17:11 ` Jacob Keller
2025-03-21 15:17 ` Kamil Zaripov
2025-03-21 17:33 ` Michael Chan
2025-03-24 15:04 ` Pavan Chebbi
2025-03-25 10:13 ` Kamil Zaripov
2025-03-25 10:41 ` Vadim Fedorenko
2025-03-25 12:24 ` Pavan Chebbi
2025-03-26 13:50 ` Kamil Zaripov
2025-03-26 20:31 ` Jacob Keller
2025-03-27 13:16 ` Pavan Chebbi
2025-04-01 20:17 ` Keller, Jacob E
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37629e9c-0a9f-4e08-921c-efbf7824c371@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=andrew.gospodarek@broadcom.com \
--cc=andrew@lunn.ch \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pavan.chebbi@broadcom.com \
--cc=zaripov-kamil@avride.ai \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).