> -----Original Message----- > From: Jakub Kicinski <kuba@xxxxxxxxxx> > Sent: Friday, November 5, 2021 10:30 PM > To: Machnikowski, Maciej <maciej.machnikowski@xxxxxxxxx> > 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).
