> -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On Behalf Of > Richard Cochran > Sent: Wednesday, August 18, 2021 10:03 AM > To: Machnikowski, Maciej <maciej.machnikowski@xxxxxxxxx> > Cc: cong.wang@xxxxxxxxxxxxx; arnd@xxxxxxxx; gustavoars@xxxxxxxxxx; > netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > colin.king@xxxxxxxxxxxxx; intel-wired-lan@xxxxxxxxxxxxxxxx; nikolay@xxxxxxxxxx; > linux-kselftest@xxxxxxxxxxxxxxx; kuba@xxxxxxxxxx; shuah@xxxxxxxxxx; > davem@xxxxxxxxxxxxx > 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
