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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <PH0PR11MB495162EC9116F197D79589F5EAFF9@PH0PR11MB4951.namprd11.prod.outlook.com>
Date:   Wed, 18 Aug 2021 22:36:03 +0000
From:   "Machnikowski, Maciej" <maciej.machnikowski@...el.com>
To:     Richard Cochran <richardcochran@...il.com>
CC:     "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "nikolay@...dia.com" <nikolay@...dia.com>,
        "cong.wang@...edance.com" <cong.wang@...edance.com>,
        "colin.king@...onical.com" <colin.king@...onical.com>,
        "gustavoars@...nel.org" <gustavoars@...nel.org>,
        "Bross, Kevin" <kevin.bross@...el.com>,
        "Stanton, Kevin B" <kevin.b.stanton@...el.com>,
        Ahmad Byagowi <abyagowi@...com>
Subject: RE: [RFC net-next 1/7] ptp: Add interface for acquiring DPLL state

> -----Original Message-----
> From: Richard Cochran <richardcochran@...il.com>
> Sent: Wednesday, August 18, 2021 7:03 PM
> To: Machnikowski, Maciej <maciej.machnikowski@...el.com>
> Cc: Kubalewski, Arkadiusz <arkadiusz.kubalewski@...el.com>; linux-
> kernel@...r.kernel.org; intel-wired-lan@...ts.osuosl.org;
> netdev@...r.kernel.org; linux-kselftest@...r.kernel.org; Brandeburg,
> Jesse <jesse.brandeburg@...el.com>; Nguyen, Anthony L
> <anthony.l.nguyen@...el.com>; davem@...emloft.net; kuba@...nel.org;
> shuah@...nel.org; arnd@...db.de; nikolay@...dia.com;
> cong.wang@...edance.com; colin.king@...onical.com;
> gustavoars@...nel.org
> 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