[Intel-wired-lan] [RFC net-next 1/7] ptp: Add interface for acquiring DPLL state

[Keller, Jacob E]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces at osuosl.org> On Behalf Of
> Richard Cochran
> Sent: Wednesday, August 18, 2021 10:03 AM
> To: Machnikowski, Maciej <maciej.machnikowski at intel.com>
> Cc: cong.wang at bytedance.com; arnd at arndb.de; gustavoars at kernel.org;
> netdev at vger.kernel.org; linux-kernel at vger.kernel.org;
> colin.king at canonical.com; intel-wired-lan at lists.osuosl.org; nikolay at nvidia.com;
> linux-kselftest at vger.kernel.org; kuba at kernel.org; shuah at kernel.org;
> davem at 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