Netdev List
 help / color / mirror / Atom feed
From: Ivan Vecera <ivecera@redhat.com>
To: netdev@vger.kernel.org
Cc: Petr Oros <poros@redhat.com>,
	Chris du Quesnay <Chris.duQuesnay@microchip.com>,
	Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
	Jakub Kicinski <kuba@kernel.org>, Jiri Pirko <jiri@resnulli.us>,
	Min Li <min.li@microchip.com>, Paolo Abeni <pabeni@redhat.com>,
	Richard Cochran <richardcochran@gmail.com>,
	Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH net-next v6 2/3] dpll: zl3073x: add channel ToD, phase step and TIE operations
Date: Tue, 11 Aug 2026 14:22:36 +0200	[thread overview]
Message-ID: <2a02b878-d605-4db4-a9a1-7323beb35e4a@redhat.com> (raw)
In-Reply-To: <20260809182340.1081610-3-ivecera@redhat.com>

Sashiko findings and replies:

 > Does capturing the post-timestamp here degrade cross-timestamping
 > precision? [...]
 > Should the post-timestamp be captured immediately after
 > zl3073x_chan_tod_ctrl() issues the command?

The post-timestamp must be taken after the semaphore clears, not
after the command write. The hardware latches the ToD value as part
of processing the command, which completes when the semaphore is
cleared. Taking the post-timestamp before the wait would risk the
window not containing the actual latch event, which would be worse
than a wider but correct window.

 > Could this retry loop exhaust its budget and fail spuriously [...]?

Testing shows that a single iteration of the loop body (two ToD
reads) takes approximately 17-19 ms. With 20 retries that gives a
budget of 340-380 ms, which is more than enough to outlast the 20 ms
margin window. After the 1 Hz edge crosses, the next read returns
~980 ms of margin and the loop breaks.

 > Is it possible for preemption to cause a 1-second clock shift here?

The 20 ms threshold provides sufficient margin for the write
sequence. This requires ~20 ms of preemption under a held mutex to
cause an issue, which is not reachable in practice.

Thanks,
Ivan


  parent reply	other threads:[~2026-08-11 12:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-09 18:23 [PATCH net-next v6 0/3] dpll: zl3073x: add PTP clock support Ivan Vecera
2026-08-09 18:23 ` [PATCH net-next v6 1/3] dpll: zl3073x: scale poll interval proportionally to timeout Ivan Vecera
2026-08-11 12:19   ` Ivan Vecera
2026-08-11 12:20   ` Ivan Vecera
2026-08-09 18:23 ` [PATCH net-next v6 2/3] dpll: zl3073x: add channel ToD, phase step and TIE operations Ivan Vecera
2026-08-11 12:21   ` Ivan Vecera
2026-08-11 12:22   ` Ivan Vecera [this message]
2026-08-09 18:23 ` [PATCH net-next v6 3/3] dpll: zl3073x: add PTP clock support Ivan Vecera
2026-08-11 12:25   ` Ivan Vecera
2026-08-11 12:26   ` Ivan Vecera

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=2a02b878-d605-4db4-a9a1-7323beb35e4a@redhat.com \
    --to=ivecera@redhat.com \
    --cc=Chris.duQuesnay@microchip.com \
    --cc=arkadiusz.kubalewski@intel.com \
    --cc=corbet@lwn.net \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=min.li@microchip.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=poros@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=skhan@linuxfoundation.org \
    --cc=vadim.fedorenko@linux.dev \
    /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