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

Message-ID: <SJ2PR11MB8452D62C5F94C87C6659C5989B03A@SJ2PR11MB8452.namprd11.prod.outlook.com>
Date: Fri, 5 Sep 2025 11:14:09 +0000
From: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
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

>From: Jakub Kicinski <kuba@...nel.org>
>Sent: Saturday, August 30, 2025 2:34 AM
> 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?
> 

In this particular case the "synce" source could point to a DPLL device of EEC
type, and there is a sense to have it together in one API. Like a two pins
registered with a netdev, one is input and it would be used for clock recovery,
second is output - for tx-clk control - either using the DPLL device produced
signal or not. Probably worth to mention this is the case with 'external' DPLL,
where ice driver doesn't control a DPLL device but it could use the output as
is this 'synce' one doing.

> 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.
> 

Adding control over 'ext-ref' muds up the clean story of above.. The 'ext-ref'
source is rather an external pin, which have to be provided with external
clock signal, not defined anywhere else, or connected directly to DPLL device.
Purely HW/platform dependent. User needs to know the HW connections, the
signal to this pin could be produced with external signal generator, same host
but a different DPLL device, or simply different host and device. There can be
a PLL somewhere between generator and TX PHY but there is no lock status, thus
adding new dpll device just to model this seemed an overshot.

Exactly because of nature of 'ext-ref' decided to go with extending the
net device itself and made it separated from DPLL subsystem. 

Please share your thoughts, right now I see two ways forward:
- moving netdev netlink to rt-netlink,
- kind of hacking into dpll subsystem with 'ext-ref' and output netdev pin.

> 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".
>

I agree this could be hidden, unless there is user case for selecting one
from multiple available in the OS.

> 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.
> 

Yeah, I like generic, but after all we are all HW dependent.

Thank you!
Arkadiusz