Fri, Sep 05, 2025 at 04:09:52PM +0200, [email protected] wrote: >On 05. 09. 25 1:14 odp., Kubalewski, Arkadiusz wrote: >> > From: Jakub Kicinski <[email protected]> >> > Sent: Saturday, August 30, 2025 2:34 AM >> > On Fri, 29 Aug 2025 07:49:46 +0000 Kubalewski, Arkadiusz wrote: >> > > > From: Jakub Kicinski <[email protected]> >> > > > 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/[email protected]/ > >> > 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 >
