[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211210081654.233a41b6@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Fri, 10 Dec 2021 08:16:54 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Maciej Machnikowski <maciej.machnikowski@...el.com>
Cc: netdev@...r.kernel.org, intel-wired-lan@...ts.osuosl.org,
arkadiusz.kubalewski@...el.com, richardcochran@...il.com,
abyagowi@...com, anthony.l.nguyen@...el.com, davem@...emloft.net,
linux-kselftest@...r.kernel.org, idosch@...sch.org,
mkubecek@...e.cz, saeed@...nel.org, michael.chan@...adcom.com,
petrm@...dia.com, Vadim Fedorenko <vfedorenko@...ek.ru>
Subject: Re: [PATCH v5 net-next 0/4] Add ethtool interface for RClocks
On Fri, 10 Dec 2021 14:45:46 +0100 Maciej Machnikowski wrote:
> Synchronous Ethernet networks use a physical layer clock to syntonize
> the frequency across different network elements.
>
> Basic SyncE node defined in the ITU-T G.8264 consist of an Ethernet
> Equipment Clock (EEC) and have the ability to synchronize to reference
> frequency sources.
>
> This patch series is a prerequisite for EEC object and adds ability
> to enable recovered clocks in the physical layer of the netdev object.
> Recovered clocks can be used as one of the reference signal by the EEC.
>
> Further work is required to add the DPLL subsystem, link it to the
> netdev object and create API to read the EEC DPLL state.
You missed CCing Vadim. I guess Ccing the right people may be right up
there with naming things as the hardest things in SW development..
Anyway, Vadim - do you have an ETA on the first chunk of the PLL work?
Powered by blists - more mailing lists