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

[Machnikowski, Maciej]

> -----Original Message-----
> From: Richard Cochran <richardcochran@xxxxxxxxx>
> Sent: Thursday, August 19, 2021 5:34 PM
> To: Machnikowski, Maciej <maciej.machnikowski@xxxxxxxxx>
> Cc: Kubalewski, Arkadiusz <arkadiusz.kubalewski@xxxxxxxxx>; linux-
> kernel@xxxxxxxxxxxxxxx; intel-wired-lan@xxxxxxxxxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx; linux-kselftest@xxxxxxxxxxxxxxx; Brandeburg,
> Jesse <jesse.brandeburg@xxxxxxxxx>; Nguyen, Anthony L
> <anthony.l.nguyen@xxxxxxxxx>; davem@xxxxxxxxxxxxx; kuba@xxxxxxxxxx;
> shuah@xxxxxxxxxx; arnd@xxxxxxxx; nikolay@xxxxxxxxxx;
> cong.wang@xxxxxxxxxxxxx; colin.king@xxxxxxxxxxxxx;
> gustavoars@xxxxxxxxxx; Bross, Kevin <kevin.bross@xxxxxxxxx>; Stanton,
> Kevin B <kevin.b.stanton@xxxxxxxxx>; Ahmad Byagowi <abyagowi@xxxxxx>
> 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 interfaces
> 
> I'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