> -----Original Message----- > From: Richard Cochran <richardcochran@xxxxxxxxx> > Sent: Wednesday, August 18, 2021 7:03 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 > Subject: Re: [RFC net-next 1/7] ptp: Add interface for acquiring DPLL state > > > Additionally we'll lose ability to rely on external HW to monitor > > external TS events. > > Sorry, I can't see that at all. > > Please do NOT tack this stuff onto the PHC subsystem just because you can. > > Thanks, > Richard OK, Let's take a step back and forget about SyncE. A PTP clock is a device that has a phase and a frequency, and its frequency can be adjusted using API calls. On the other hand, there's the physical side of the PTP clock. The PTP clock can run on cheap quartz, on the CSAC, or the PLL. The first two of them will get a clock signal from a passive device, but in the PLL case, it'll get it from an active one. If it runs on an active PLL device, you get another place that adjusts the frequency of your PTP clock. No matter what source you use as a reference for it - CSAC, SyncE, or GNSS receiver. Adding the PLL state to the PTP subsystem is just another indicator of the state of the PTP clock. The upper layer can use it, or ignored it, but it fits into the timer subsystem, as the time generated by the PTP on top will be derived from the frequency generated by the PLL. And it is applicable to both a PHC and a completely separate implementation of timer, like the one that's present in the Time Card . Regards Maciek
