-----Original Message----- From: Intel-wired-lan intel-wired-lan-bounces@osuosl.org On Behalf Of Richard Cochran Sent: Wednesday, August 18, 2021 10:03 AM To: Machnikowski, Maciej maciej.machnikowski@intel.com Cc: cong.wang@bytedance.com; arnd@arndb.de; gustavoars@kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; colin.king@canonical.com; intel-wired-lan@lists.osuosl.org; nikolay@nvidia.com; linux-kselftest@vger.kernel.org; kuba@kernel.org; shuah@kernel.org; davem@davemloft.net Subject: Re: [Intel-wired-lan] [RFC net-next 1/7] ptp: Add interface for acquiring DPLL state
On Tue, Aug 17, 2021 at 09:41:49AM +0000, Machnikowski, Maciej wrote:
The logic behind adding the DPLL state to the PTP subsystem is that SyncE DPLL
on Network adapters, in most cases, drive the PTP timer.
So what? The logic in the HW has nothing to do with the proper user space interfaces. For example, we have SO_TIMESTAMPING and PHC as separate APIs, even though HW devices often implement both.
Having access to it in the PTP subsystem is beneficial, as Telco standards, like G.8275.1/2, require a different behavior depending on the SyncE availability and state.
Right, but this does say anything about the API.
Multiport adapters use a single PLL to drive all ports. If we add the PLL interface to the PTP device - a tool that would implement support for Telco standards would have a single source of information about the presence and state of physical sync.
Not really. Nothing guarantees a sane mapping from MAC to PHC. In many systems, there a many of each.
Well, I think the point of placing it in the PTP subsystem is that there is a sane mapping between PHC <-> DPLL. There's only one DPLL for the PHC.
Thanks, Jake