[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZGvLm0Cxh+skT6zB@hoboy.vegasvil.org>
Date: Mon, 22 May 2023 13:07:55 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Rahul Rameshbabu <rrameshbabu@...dia.com>
Cc: netdev@...r.kernel.org, Saeed Mahameed <saeed@...nel.org>,
Gal Pressman <gal@...dia.com>, Tariq Toukan <tariqt@...dia.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Jacob Keller <jacob.e.keller@...el.com>
Subject: Re: [PATCH net-next 1/9] ptp: Clarify ptp_clock_info .adjphase
expects an internal servo to be used
On Mon, May 22, 2023 at 10:03:23AM -0700, Rahul Rameshbabu wrote:
> This point makes sense to me. However, I have a concern about the case
> where the linuxptp servo has not had a chance to make a single frequency
> adjustment (0 ppb) and .adjphase/LOCKED_STABLE state is initially
> called/reached. After converging, the frequency will be close to the
> remote time's server's frequency, but that frequency will likely not be
> 0 ppb. If .adjfine had been called previously, the difference between
> the remote time server's frequency and the cached frequency in the ptp
> stack would likely be significantly closer. That said, do you think it
> makes sense to have some kind of API that gives information about the
> in-HW controller such as the frequency offset it operated? Or maybe in
> general an API in the future for introspecting the state of this in-HW
> servo?
The whole point of hardware vendors doing this is to hide their
implementation from prying eyes. So they are not going to provide
introspection at all.
Thanks,
Richard
Powered by blists - more mailing lists