RE: [PATCH v5 net-next 0/8] dpll/ice: Add TXC DPLL type and full TX reference clock control for E825

[Nitka, Grzegorz]

> -----Original Message-----
> From: Jakub Kicinski <kuba@xxxxxxxxxx>
> Sent: Friday, April 10, 2026 10:38 PM
> To: Nitka, Grzegorz <grzegorz.nitka@xxxxxxxxx>
> Cc: netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; intel-wired-
> lan@xxxxxxxxxxxxxxxx; Oros, Petr <poros@xxxxxxxxxx>;
> richardcochran@xxxxxxxxx; andrew+netdev@xxxxxxx; Kitszel, Przemyslaw
> <przemyslaw.kitszel@xxxxxxxxx>; Nguyen, Anthony L
> <anthony.l.nguyen@xxxxxxxxx>; Prathosh.Satish@xxxxxxxxxxxxx; Vecera,
> Ivan <ivecera@xxxxxxxxxx>; jiri@xxxxxxxxxxx; Kubalewski, Arkadiusz
> <arkadiusz.kubalewski@xxxxxxxxx>; vadim.fedorenko@xxxxxxxxx;
> donald.hunter@xxxxxxxxx; horms@xxxxxxxxxx; pabeni@xxxxxxxxxx;
> davem@xxxxxxxxxxxxx; edumazet@xxxxxxxxxx
> Subject: Re: [PATCH v5 net-next 0/8] dpll/ice: Add TXC DPLL type and full TX
> reference clock control for E825
> 
> On Fri, 10 Apr 2026 14:23:58 +0000 Nitka, Grzegorz wrote:
> > Here is the high-level connection diagram for E825 device. I hope you find it
> helpful:
> > [..]
> 
> It does thanks a lot.
> 
> > Before this series, we tried different approaches.
> > One of them was to create MUX pin associated with netdev interface.
> > EXT_REF and SYNCE pins were registered with this MUX pin.
> > However I recall there were at least two issues with this solution:
> > - when using DPLL subsystem not all the connections/relations were visible
> >   from DPLL pin-get perspective. RT netlink was required
> > - due to mixing pins from different modules (like fwnode based pin from zl
> driver
> >   and the pins from ice), we were not able to safely clean the references
> between
> >   pins and dpll (basicaly .. we observed crashes)
> >
> > Proposed solution just seems to be clean and fully reflects current
> > connection topology.
> 
> Do you have the link to the old proposal that was adding stuff to
> rtnetlink? I remember some discussion long-ish ago, maybe I was wrong.
> 

Hello Jakub,

This is the patch from the discussion I put the link in the cover letter:
https://lore.kernel.org/netdev/20250828164345.116097-1-arkadiusz.kubalewski@xxxxxxxxx/

Regards

Grzegorz

> > What's actually your biggest concern?
> > The fact we introduce a new DPLL type? Or multiply DPLL instances? Or
> both?
> > Do you prefer to see "one big" DPLL with 16 pins in our case (8 ports x 2 tx-
> clk pins)?
> > Each pin with the name like, for example, PF0-SyncE/PF0-eRef etc.?
> 
> My concern is that I think this is a pretty run of the mill SyncE
> design. If we need to pretend we have two DPLLs here if we really
> only have one and a mux - then our APIs are mis-designed :(