Message-ID: <psjeuxy3ofoh544u4ag6xcfosb72bsfvfcnfzip3swprn4mzua@2owku2txa5oi>
Date: Tue, 16 Sep 2025 14:13:50 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Ivan Vecera <ivecera@...hat.com>
Cc: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>, 
	Jakub Kicinski <kuba@...nel.org>, "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>, "Loktionov, Aleksandr" <aleksandr.loktionov@...el.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>, 
	Rob Herring <robh@...nel.org>
Subject: Re: [RFC PATCH v2] net: add net-device TX clock source selection
 framework

Fri, Sep 05, 2025 at 04:09:52PM +0200, ivecera@...hat.com wrote:
>On 05. 09. 25 1:14 odp., Kubalewski, Arkadiusz wrote:
>> > 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.
>
>Yes, this simply describes a diagram I described in my DT RFC [1] that
>defines relationship between DPLL device and network card.
>
>		   +-----------+
>		+--|   NIC 1   |<-+
>		|  +-----------+  |
>		|                 |
>		| RxCLK     TxCLK |
>		|                 |
>		|  +-----------+  |
>		+->| channel 1 |--+
>+------+	   |-- DPLL ---|
>| GNSS |---------->| channel 2 |--+
>+------+  RefCLK   +-----------+  |
>				  |
>			    TxCLK |
>				  |
>		   +-----------+  |
>		   |   NIC 2   |<-+
>		   +-----------+
>
>Here we have 2 scenarios... The first (NIC1) is a SyncE one where NIC1
>feeds some DPLL input reference with recovered clock and consumes the
>synchronized signal from the DPLL output pin as Tx clock. In the second
>(NIC2) case the NIC uses some DPLL output pin signal as Tx clock and
>the DPLL is synchronized with some external source.
>
>If I understand well your comment, the RxCLK above is the dpll_pin
>currently present in net_device. The TxCLK for the first case (NIC1)
>should be the dpll_pin you are calling as "synce" source. And TxCLK for
>the second case (NIC2) should be the dpll_pin you are calling "ext-ref".
>Is it correct?
>
>If so there should be another dpll_pin in the net_device let's call it
>tx_dpll_pin... The existing one should be some input pin of some DPLL device
>and the tx_dpll_pin should be some output pin of that device.
>
>A user could set the tx_dpll_pin by ip link command like:
>
># ip link set eth0 txclk <dpll-pin-id>

Makes sense. We have dpll to model this and connection between dpll and
netdev worlds over the pin-link (RX/source). To extend this to add the
other direction seems correct.


>
>[1] https://patchwork.kernel.org/project/netdevbpf/patch/20250815144736.1438060-1-ivecera@redhat.com/
>
>> > 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.
>
>You are mentioning above the case where an external DPLL device that is
>not under control of network driver (e.g. DPLL chip on motherboard and
>some LOM NIC). In this case is currently impossible for the NIC driver
>to report dpll_pin used for recovered clock as it does not control the
>DPLL device and all dpll_devices and dpll_pins are registered by the
>different driver.
>
>There could be defined some DT schema for the relations between ethernet
>controller and used DPLL device. Then the system firmware (DT/ACPI...)
>could provide the wiring info (e.g. DPLL pin REF0P is used for recovered
>clock from NIC1 and output pin OUT4P for the Tx clock by NIC1 etc.)
>
>...and also there should be some DPLL API for the drivers that would
>allow to access DPLL devices and pins. E.g. NIC driver reads from its
>fwnode that possible tx-clock pins could be out_pin1, 3, 5 but it needs
>to translate fwnode_handles of these pins to registered DPLL pin IDs.
>
>Thanks,
>Ivan
>

Powered by blists - more mailing lists