[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y9AuU4zSQ0++RV7z@hoboy.vegasvil.org>
Date: Tue, 24 Jan 2023 11:15:31 -0800
From: Richard Cochran <richardcochran@...il.com>
To: Bar Shapira <bar.shapira.work@...il.com>
Cc: Rahul Rameshbabu <rrameshbabu@...dia.com>,
Jakub Kicinski <kuba@...nel.org>,
Jacob Keller <jacob.e.keller@...el.com>,
Saeed Mahameed <saeed@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
Saeed Mahameed <saeedm@...dia.com>, netdev@...r.kernel.org,
Tariq Toukan <tariqt@...dia.com>,
Gal Pressman <gal@...dia.com>,
Vincent Cheng <vincent.cheng.xh@...esas.com>
Subject: Re: [net-next 03/15] net/mlx5: Add adjphase function to support
hardware-only offset control
On Tue, Jan 24, 2023 at 12:33:05PM +0200, Bar Shapira wrote:
> I guess this expectation should be part of the documentation too, right? Are
> there more expectations when calling adjphase?
I'll gladly ack improvements to the documentation. I myself won't
spend time on that, because it will only get ignored, even when it is
super clear. Like ptp_clock_register(), for example.
> In previous responses on the mailing list it said that adjphase should not
> cause the time to 'jump' - is it also correct?
correct.
> It seems that "Feeds the given phase offset into the hardware clock's servo"
> is still missing some information.
> Can you help clarify the expected result after calling adjphase from SW?
If you don't have a servo implemented in hardware, then don't
implement .adjphase in your device driver.
Thanks,
Richard
Powered by blists - more mailing lists