linux-kernel - Re: [RFC PATCH v2] net: add net-device TX clock source selection framework

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] [day] [month] [year] [list]

Message-ID: <20250829173414.329d8426@kernel.org>
Date: Fri, 29 Aug 2025 17:34:14 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
Cc: "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>, "Kitszel, Przemyslaw"
 <przemyslaw.kitszel@...el.com>, "andrew+netdev@...n.ch"
 <andrew+netdev@...n.ch>, "davem@...emloft.net" <davem@...emloft.net>,
 "edumazet@...gle.com" <edumazet@...gle.com>, "pabeni@...hat.com"
 <pabeni@...hat.com>, "horms@...nel.org" <horms@...nel.org>,
 "sdf@...ichev.me" <sdf@...ichev.me>, "almasrymina@...gle.com"
 <almasrymina@...gle.com>, "asml.silence@...il.com"
 <asml.silence@...il.com>, "leitao@...ian.org" <leitao@...ian.org>,
 "kuniyu@...gle.com" <kuniyu@...gle.com>, "jiri@...nulli.us"
 <jiri@...nulli.us>, "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>,
 "Vecera, Ivan" <ivecera@...hat.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>
Subject: Re: [RFC PATCH v2] net: add net-device TX clock source selection
 framework

On Fri, 29 Aug 2025 07:49:46 +0000 Kubalewski, Arkadiusz wrote:
> >From: Jakub Kicinski <kuba@...nel.org>
> >Sent: Friday, August 29, 2025 12:32 AM
> >
> >On Thu, 28 Aug 2025 18:43:45 +0200 Arkadiusz Kubalewski wrote:  
> >> Add support for user-space control over network device transmit clock
> >> sources through a new extended netdevice netlink interface.
> >> A network device may support multiple TX clock sources (OCXO, SyncE
> >> reference, external reference clocks) which are critical for
> >> time-sensitive networking applications and synchronization protocols.  
> >
> >how does this relate to the dpll pin in rtnetlink then?  
> 
> In general it doesn't directly. However we could see indirect relation
> due to possible DPLL existence in the equation.
> 
> The rtnetlink pin was related to feeding the dpll with the signal,
> here is the other way around, by feeding the phy TX of given interface
> with user selected clock source signal.
> 
> Previously if our E810 EEC products with DPLL, all the ports had their
> phy TX fed with the clock signal generated by DPLL.
> For E830 the user is able to select if the signal is provided from: the
> EEC DPLL(SyncE), provided externally(ext_ref), or OCXO.
> 
> I assume your suggestion to extend rtnetlink instead of netdev-netlink?

Yes, for sure, but also I'm a little worried about this new API
duplicating the DPLL, just being more "shallow".

What is the "synce" option for example? If I set the Tx clock to SyncE
something is feeding it from another port, presumably selected by FW or
some other tooling?

Similar on ext-ref, there has to be a DPLL somewhere in the path,
in case reference goes away? We assume user knows what "ext-ref" means,
it's not connected to any info within Linux, DPLL or PTP.

OXCO is just an oscillator on the board without a sync. What kind of
XO it is likely an unnecessary detail in the context of "what reference
drives the eth clock".

All of these things may make perfect sense when you look at a
particular product, but for a generic Linux kernel uAPI it does not
feel very natural.