-----Original Message----- From: Richard Cochran richardcochran@gmail.com Sent: Thursday, August 19, 2021 5:34 PM To: Machnikowski, Maciej maciej.machnikowski@intel.com Cc: Kubalewski, Arkadiusz arkadiusz.kubalewski@intel.com; linux- kernel@vger.kernel.org; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-kselftest@vger.kernel.org; Brandeburg, Jesse jesse.brandeburg@intel.com; Nguyen, Anthony L anthony.l.nguyen@intel.com; davem@davemloft.net; kuba@kernel.org; shuah@kernel.org; arnd@arndb.de; nikolay@nvidia.com; cong.wang@bytedance.com; colin.king@canonical.com; gustavoars@kernel.org; Bross, Kevin kevin.bross@intel.com; Stanton, Kevin B kevin.b.stanton@intel.com; Ahmad Byagowi abyagowi@fb.com Subject: Re: [RFC net-next 1/7] ptp: Add interface for acquiring DPLL state
On Wed, Aug 18, 2021 at 10:36:03PM +0000, Machnikowski, Maciej wrote:
OK, Let's take a step back and forget about SyncE.
Ahem, the title of this series is:
[RFC net-next 0/7] Add basic SyncE interfacesI'd be happy to see support for configuring SyncE.
But I guess this series is about something totally different.
Thanks, Richard
If it helps we'd be happy to separate that in 2 separate RFCs. This was squashed together under SyncE support umbrella to show one of the use cases, but PTP changes are more generic and cover all PTP clocks that use DPLL for the physical clock generation.
Regards Maciek