[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CO1PR11MB5089A30F5681B860B3F9F96CD6FF9@CO1PR11MB5089.namprd11.prod.outlook.com>
Date: Wed, 18 Aug 2021 18:14:13 +0000
From: "Keller, Jacob E" <jacob.e.keller@...el.com>
To: Richard Cochran <richardcochran@...il.com>,
"Machnikowski, Maciej" <maciej.machnikowski@...el.com>
CC: "cong.wang@...edance.com" <cong.wang@...edance.com>,
"arnd@...db.de" <arnd@...db.de>,
"gustavoars@...nel.org" <gustavoars@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"colin.king@...onical.com" <colin.king@...onical.com>,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
"nikolay@...dia.com" <nikolay@...dia.com>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"kuba@...nel.org" <kuba@...nel.org>,
"shuah@...nel.org" <shuah@...nel.org>,
"davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [Intel-wired-lan] [RFC net-next 1/7] ptp: Add interface for
acquiring DPLL state
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of
> Richard Cochran
> Sent: Wednesday, August 18, 2021 10:03 AM
> To: Machnikowski, Maciej <maciej.machnikowski@...el.com>
> Cc: cong.wang@...edance.com; arnd@...db.de; gustavoars@...nel.org;
> netdev@...r.kernel.org; linux-kernel@...r.kernel.org;
> colin.king@...onical.com; intel-wired-lan@...ts.osuosl.org; nikolay@...dia.com;
> linux-kselftest@...r.kernel.org; kuba@...nel.org; shuah@...nel.org;
> davem@...emloft.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
Powered by blists - more mailing lists