netdev - RE: [PATCH net-next 6/6] docs: net: Add description of SyncE interfaces

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: <MW5PR11MB58126A63061BFACB81A98194EA8F9@MW5PR11MB5812.namprd11.prod.outlook.com>
Date:   Sat, 6 Nov 2021 00:01:02 +0000
From:   "Machnikowski, Maciej" <maciej.machnikowski@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        "abyagowi@...com" <abyagowi@...com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "idosch@...sch.org" <idosch@...sch.org>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>,
        "saeed@...nel.org" <saeed@...nel.org>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>
Subject: RE: [PATCH net-next 6/6] docs: net: Add description of SyncE
 interfaces

> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Friday, November 5, 2021 10:30 PM
> To: Machnikowski, Maciej <maciej.machnikowski@...el.com>
> Subject: Re: [PATCH net-next 6/6] docs: net: Add description of SyncE
> interfaces
> 
> On Fri, 5 Nov 2021 11:51:48 +0000 Machnikowski, Maciej wrote:
> > > I'm still struggling to understand your reasoning around not making
> > > EEC its own object. "We can do this later" seems like trading
> > > relatively little effort now for extra work for driver and application
> > > developers for ever.
> >
> > That's not the case. We need EEC and the other subsystem we wanted
> > to make is the DPLL subsystem. While EEC can be a DPLL - it doesn't have
> > to, and it's also the other way round - the DPLL can have numerous
> different
> > usages.
> 
> We wanted to create a DPLL object to the extent that as a SW guy
> I don't understand the difference between that and an EEC. Whatever
> category of *PLL etc. objects EEC is, that's what we want to model.

The DPLL has more uses than just EEC. I.e. Timing card uses one to generate
different frequencies synchronized to 1PPS coming from the GNSS receiver.

Implementing the whole DPLL subsystem may be an overkill for some
basic solutions that are embedded inside the PHY and only handle the
syntonization of TX frequency to the RX one. In this case all they would
report is the current state.

> > When we add the DPLL subsystem support the future work will be as
> simple
> > as routing the EEC state read function to the DPLL subsystem. But if
> someone
> > decides to use a different HW implementation he will still be able to
> > implement his own version of API to handle it without a bigger DPLL block
> 
> All we want is something that's not a port to hang whatever attributes
> exist in RTM_GETEECSTATE.

Routing to the DPLL object will be a specific use-case required only
if we support advanced cases with external sources of frequency
(like an atomic clock).