Message-ID: <a20848db-868c-457b-bb6b-9959922a3d56@redhat.com>
Date: Fri, 5 Sep 2025 16:09:52 +0200
From: Ivan Vecera <ivecera@...hat.com>
To: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>,
 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>,
 "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

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>

[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