Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Keller, Jacob E" <jacob.e.keller@intel.com>
To:     Richard Cochran <richardcochran@gmail.com>,
        "Machnikowski, Maciej" <maciej.machnikowski@intel.com>
CC:     "cong.wang@bytedance.com" <cong.wang@bytedance.com>,
        "arnd@arndb.de" <arnd@arndb.de>,
        "gustavoars@kernel.org" <gustavoars@kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "colin.king@canonical.com" <colin.king@canonical.com>,
        "intel-wired-lan@lists.osuosl.org" <intel-wired-lan@lists.osuosl.org>,
        "nikolay@nvidia.com" <nikolay@nvidia.com>,
        "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "shuah@kernel.org" <shuah@kernel.org>,
        "davem@davemloft.net" <davem@davemloft.net>
Subject: RE: [Intel-wired-lan] [RFC net-next 1/7] ptp: Add interface for
 acquiring DPLL state
Thread-Topic: [Intel-wired-lan] [RFC net-next 1/7] ptp: Add interface for
 acquiring DPLL state
Thread-Index: AQHXkrpGZc2YC9udeU2jnSf+yoigt6t2zoSAgACkO4CAAg2XgIAAEo7A
Date:   Wed, 18 Aug 2021 18:14:13 +0000
Message-ID: <CO1PR11MB5089A30F5681B860B3F9F96CD6FF9@CO1PR11MB5089.namprd11.prod.outlook.com>
References: <20210816160717.31285-1-arkadiusz.kubalewski@intel.com>
 <20210816160717.31285-2-arkadiusz.kubalewski@intel.com>
 <20210816235400.GA24680@hoboy.vegasvil.org>
 <PH0PR11MB4951762ECB04D90D634E905DEAFE9@PH0PR11MB4951.namprd11.prod.outlook.com>
 <20210818170259.GD9992@hoboy.vegasvil.org>
In-Reply-To: <20210818170259.GD9992@hoboy.vegasvil.org>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.5.1.3
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9EfpiMGPVX28X8TWSQrU0OLpKcKd4SnO31t4NPWFAZGiLxnSXM2QG/Pg4+KV?=
 =?us-ascii?Q?1SfejKGnkELh7PAZ+uXjTEwxz4JIyI6e9qUNHe37++2UaU0EwVmBpTvrqVF9?=
 =?us-ascii?Q?q+3QkFdOo+ZpJX0FdESXulwJWYcClaaVa3nh5bO1/s25wEAAo/ayqyeaAA5M?=
 =?us-ascii?Q?v4Ez/kpY9bqpxPbQr4LkA9G5UZWSnuazOL0vmdu7gMs1SimO19zfmIQ/9e8Q?=
 =?us-ascii?Q?pdjatEUbgdw0n8BkLEF9vO9wRO4zNOuJTHAOTh9LOPrKjJlphmBI3qZRnGWY?=
 =?us-ascii?Q?Vvdj/O809rUXRL0lfcxWta5JNGq9d5hhYpT4CJgl7Y8bwbv7b1DW4D1/IbZA?=
 =?us-ascii?Q?9koif8FCwYsLHJBF0+wuJwejvbgpli6dMC39GaDgifqwLL2DSxoV/WwyIU0P?=
 =?us-ascii?Q?MSOZr7OsHXUWEM2lbsXxEZ+JFhN/GekFakGDpUgdcS9dn34e2zs3SHy9f7Ru?=
 =?us-ascii?Q?pAW5QdidhcggbqGnmz/853kXxIOpnCdGyKpbXWF6Hz/MWhghMrDzKNaBq7Kl?=
 =?us-ascii?Q?UW2VMeYy8rlkAjHzs35pXyewJgJa3xIxMUYZ9QRoguPHSghHQPChPUzf+sAL?=
 =?us-ascii?Q?ggsEhqjoJwx4eczwzqSK9IhPKNDrCQiYHVdodWfWA29nhr6w2p60wCSi5Naw?=
 =?us-ascii?Q?CEtXPhy2U8eJhL9W7p+PDNLJhCseH9OX8Y281fJg6TYJBro9uB88cASWW0+W?=
 =?us-ascii?Q?pJCtBU89PU0Sf2xEoawIrHCh3DCGkXcYRSEf1nFYPYgEzUVCO4dH05CHLgxf?=
 =?us-ascii?Q?IDzlFB8gkz9EZlCubTpYKSZKJ2sZDPORBCe6HGel9uSvkLP6XMfhvshXg9ha?=
 =?us-ascii?Q?dcPi/IUK24KhRT+9iScHNsX3En1kKSRjjjbL+tgnioSsB1J5S5aL6skFR/Fj?=
 =?us-ascii?Q?iriMly5dE5xUH75c6elIa7ZoVsrQ5ZtsZGsBlgE8oeixwmSkZBbl77jXoba/?=
 =?us-ascii?Q?/E/be5nW7+riRhuch1tlOBjTEf/9DXUvnH7DJo5I4YaD4HuT+yrymCgtFGIg?=
 =?us-ascii?Q?A/NrWbBU054eGeN41DDmrMTD39sAMBIQGAJgtAIzUJpz7DUHHpI6LKpvSdtb?=
 =?us-ascii?Q?qX2ODpqYQLSF6nYc4wk3SQhEA5PC1oNO7Y17rgYl77axO0zeaqM+QvAwNi9K?=
 =?us-ascii?Q?KMOiSxT0LLAMmxEhsCBHZR6U5FD4QEeTC6TbuCgUvlTd4DUuxNVR7WKzMe/a?=
 =?us-ascii?Q?CMNfd01zm7QvRwNR1uvqV1dT3bBkU33n4gdtkhmXqr83FlVuLhSkxE5kc1jU?=
 =?us-ascii?Q?Rm1MYS+3Z7DJYm3SAWcFCjjJdvcMGEul+04RjnS3q79Z5Omm8GIMSpWBmgYW?=
 =?us-ascii?Q?qYc=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5089.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4654f27e-5da5-463f-48eb-08d96273fbf5
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2021 18:14:13.7154
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Cp9Q0pnSB5SvM3+kttKexG17UP7ViprhPd2PtP8MonF1vwf1dcVJnoCfcbp1P6BlprP7D3HtpDQfuzHrfcunE9NbgpgbkZzXByXnby+/vOU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2078
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> -----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@nvidi=
a.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
>=20
> On Tue, Aug 17, 2021 at 09:41:49AM +0000, Machnikowski, Maciej wrote:
>=20
> > The logic behind adding the DPLL state to the PTP subsystem is that Syn=
cE DPLL
> on Network adapters, in most cases, drive the PTP timer.
>=20
> 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.
>=20
> > 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.
>=20
> Right, but this does say anything about the API.
>=20
> > 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.
>=20
> Not really.  Nothing guarantees a sane mapping from MAC to PHC.  In
> many systems, there a many of each.
>=20

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