>From: Jakub Kicinski <kuba@kernel.org>
>Sent: Friday, April 10, 2026 10:38 PM
>
>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.
>
>> 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 :(

Well, the true is that we did not anticipated per-port control of the
TX clock source, as a single DPLL device could drive multiple of such.

This is not true, that we pretend there is a second PLL - there is a
PLL on each TX clock, maybe not a full DPLL, but still the loop with
a control over it's sources is there and it has the same 2 external
sources + default XO.

A mentioned try of adding per port MUX-type pin, just to give some control
to the user, is where we wanted to simplify things, but in the end the API
would have to be modified in significant way, various paths related to pin
registration and keeping correct references, just to make working case
for the pin_on_pin_register and it's internals. We decided that the burden
and impact for existing design was to high.

And that is why the TXC approach emerged, the change of DPLL is minimal,
The model is still correct from user perspective, SyncE SW controller shall
anticipate possibility that per-port TXC dpll is there 

This particular device and driver doesn't implement any EEC-type DPLL
device, the one could think that we can just change the type here and use
EEC type instead of new one TXC - since we share pins from external dpll
driver, which is EEC type, and our DPLL device would have different clock_id
and module. But, further designs, where a single NIC is having control over
both a EEC DPLL and ability to control each source per-port this would be
problematic. At least one NIC Port driver would have to have 2 EEC-type DPLLs
leaving user with extra confusion.

Thanks,
Arkadiusz

On Mon, 13 Apr 2026 08:19:30 +0000 Kubalewski, Arkadiusz wrote:
>> 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 :(  
> 
> Well, the true is that we did not anticipated per-port control of the
> TX clock source, as a single DPLL device could drive multiple of such.
> 
> This is not true, that we pretend there is a second PLL - there is a
> PLL on each TX clock, maybe not a full DPLL, but still the loop with
> a control over it's sources is there and it has the same 2 external
> sources + default XO.

Don't we put that MAC PLL into bypass mode if we feed a clock from
the EEC DPLL?

> A mentioned try of adding per port MUX-type pin, just to give some control
> to the user, is where we wanted to simplify things, but in the end the API
> would have to be modified in significant way, various paths related to pin
> registration and keeping correct references, just to make working case
> for the pin_on_pin_register and it's internals. We decided that the burden
> and impact for existing design was to high.
> 
> And that is why the TXC approach emerged, the change of DPLL is minimal,
> The model is still correct from user perspective, SyncE SW controller shall
> anticipate possibility that per-port TXC dpll is there 

We are starting to push into what was previously the domain of
drivers/clk, tho. IIUC the "ASIC PLL"s are usually integrated with
clock dividers. And cannot be "configured" after chip init / async
reset (which is why I presume you whack a reset in patch 7?).

> This particular device and driver doesn't implement any EEC-type DPLL
> device, the one could think that we can just change the type here and use
> EEC type instead of new one TXC - since we share pins from external dpll
> driver, which is EEC type, and our DPLL device would have different clock_id
> and module. But, further designs, where a single NIC is having control over
> both a EEC DPLL and ability to control each source per-port this would be
> problematic. At least one NIC Port driver would have to have 2 EEC-type DPLLs
> leaving user with extra confusion.

The distinction between TXC and EEC dpll is confusing. 
I thought EEC one _was_supposed_to_ drive the Tx clock?
What PPS means is obvious, what EEC means if not driving Tx clock is
unclear to me..

Let me summarize my concerns - we need to navigate the split between
drivers/clk and dpll. We need a distinction on what goes where, because
every ASIC has a bunch of PLLs which until now have been controlled by
device tree (if at all). If the main question we want to answer is
"which clock ref is used to drive internal clock" all we need is a MUX.
If we want to make dpll cover also ASIC PLLs for platforms without
device tree we need a more generic name than TXC, IMHO.

>From: Jakub Kicinski <kuba@kernel.org>
>Sent: Tuesday, April 14, 2026 11:59 PM
>
>On Mon, 13 Apr 2026 08:19:30 +0000 Kubalewski, Arkadiusz wrote:
>>> 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 :(
>>
>> Well, the true is that we did not anticipated per-port control of the
>> TX clock source, as a single DPLL device could drive multiple of such.
>>
>> This is not true, that we pretend there is a second PLL - there is a
>> PLL on each TX clock, maybe not a full DPLL, but still the loop with
>> a control over it's sources is there and it has the same 2 external
>> sources + default XO.
>
>Don't we put that MAC PLL into bypass mode if we feed a clock from
>the EEC DPLL?

This HW doesn't use EEC DPLL signal to feed MAC clock, as DPLL is
external from NIC point of view. Only 2 signals from such external DPLL
device are used by NIC:
- synce (a single source for all those TXC per-port DPLL device)
- time_ref (a source for the TS_PLL - which drives PTP timer)

Grzegorz is now working on submitting the patches for later one.

>
>> A mentioned try of adding per port MUX-type pin, just to give some
>>control
>> to the user, is where we wanted to simplify things, but in the end the
>>API
>> would have to be modified in significant way, various paths related to
>>pin
>> registration and keeping correct references, just to make working case
>> for the pin_on_pin_register and it's internals. We decided that the
>>burden
>> and impact for existing design was to high.
>>
>> And that is why the TXC approach emerged, the change of DPLL is minimal,
>> The model is still correct from user perspective, SyncE SW controller
>>shall
>> anticipate possibility that per-port TXC dpll is there
>
>We are starting to push into what was previously the domain of
>drivers/clk, tho. IIUC the "ASIC PLL"s are usually integrated with
>clock dividers. And cannot be "configured" after chip init / async
>reset (which is why I presume you whack a reset in patch 7?).

Well, we need CGU-dividers change for a frequency-compliance with lower
link speeds, the link reset which is required as part of tx-clk switch
and link establishment on a new clock.

>
>> This particular device and driver doesn't implement any EEC-type DPLL
>> device, the one could think that we can just change the type here and
>>use
>> EEC type instead of new one TXC - since we share pins from external dpll
>> driver, which is EEC type, and our DPLL device would have different
>>clock_id
>> and module. But, further designs, where a single NIC is having control
>>over
>> both a EEC DPLL and ability to control each source per-port this would
>>be
>> problematic. At least one NIC Port driver would have to have 2 EEC-type
>>DPLLs
>> leaving user with extra confusion.
>
>The distinction between TXC and EEC dpll is confusing.
>I thought EEC one _was_supposed_to_ drive the Tx clock?
>What PPS means is obvious, what EEC means if not driving Tx clock is
>unclear to me..
>

Yes, correct, EEC DPLL main task would be to drive TX clocks of NIC
ports, but if there is a per-port control something extra is required.

>Let me summarize my concerns - we need to navigate the split between
>drivers/clk and dpll. We need a distinction on what goes where, because
>every ASIC has a bunch of PLLs which until now have been controlled by
>device tree (if at all). If the main question we want to answer is
>"which clock ref is used to drive internal clock" all we need is a MUX.
>If we want to make dpll cover also ASIC PLLs for platforms without
>device tree we need a more generic name than TXC, IMHO.

Well, 'floating' MUX type pin not connected to any dpll would require a
lot of additional implementations, just to allow source selection, as we
have tried it already.

Wouldn't more generic name cause a DPLL purpose problem?
We still want to make sure that given DPLL device would serve the role
of source selection for particular port where a source pin should be an
output either on EEC dpll or some external signal generator but somehow
related to SyncE or similar solutions.

Thanks,
Arkadiusz

On Wed, 15 Apr 2026 13:23:22 +0000 Kubalewski, Arkadiusz wrote:
> >> Well, the true is that we did not anticipated per-port control of the
> >> TX clock source, as a single DPLL device could drive multiple of such.
> >>
> >> This is not true, that we pretend there is a second PLL - there is a
> >> PLL on each TX clock, maybe not a full DPLL, but still the loop with
> >> a control over it's sources is there and it has the same 2 external
> >> sources + default XO.  
> >
> >Don't we put that MAC PLL into bypass mode if we feed a clock from
> >the EEC DPLL?  
> 
> This HW doesn't use EEC DPLL signal to feed MAC clock, as DPLL is
> external from NIC point of view. Only 2 signals from such external DPLL
> device are used by NIC:
> - synce (a single source for all those TXC per-port DPLL device)
> - time_ref (a source for the TS_PLL - which drives PTP timer)

No bypass? The PLL is actually in the loop? oof, this is beyond 
my understanding of clocks and signals :S

> >> A mentioned try of adding per port MUX-type pin, just to give some
> >>control
> >> to the user, is where we wanted to simplify things, but in the end the
> >>API
> >> would have to be modified in significant way, various paths related to
> >>pin
> >> registration and keeping correct references, just to make working case
> >> for the pin_on_pin_register and it's internals. We decided that the
> >>burden
> >> and impact for existing design was to high.
> >>
> >> And that is why the TXC approach emerged, the change of DPLL is minimal,
> >> The model is still correct from user perspective, SyncE SW controller
> >>shall
> >> anticipate possibility that per-port TXC dpll is there  
> >
> >We are starting to push into what was previously the domain of
> >drivers/clk, tho. IIUC the "ASIC PLL"s are usually integrated with
> >clock dividers. And cannot be "configured" after chip init / async
> >reset (which is why I presume you whack a reset in patch 7?).  
> 
> Well, we need CGU-dividers change for a frequency-compliance with lower
> link speeds, the link reset which is required as part of tx-clk switch
> and link establishment on a new clock.
> 
> >  
> >> This particular device and driver doesn't implement any EEC-type DPLL
> >> device, the one could think that we can just change the type here and
> >>use
> >> EEC type instead of new one TXC - since we share pins from external dpll
> >> driver, which is EEC type, and our DPLL device would have different
> >>clock_id
> >> and module. But, further designs, where a single NIC is having control
> >>over
> >> both a EEC DPLL and ability to control each source per-port this would
> >>be
> >> problematic. At least one NIC Port driver would have to have 2 EEC-type
> >>DPLLs
> >> leaving user with extra confusion.  
> >
> >The distinction between TXC and EEC dpll is confusing.
> >I thought EEC one _was_supposed_to_ drive the Tx clock?
> >What PPS means is obvious, what EEC means if not driving Tx clock is
> >unclear to me..
> >  
> 
> Yes, correct, EEC DPLL main task would be to drive TX clocks of NIC
> ports, but if there is a per-port control something extra is required.
> 
> >Let me summarize my concerns - we need to navigate the split between
> >drivers/clk and dpll. We need a distinction on what goes where, because
> >every ASIC has a bunch of PLLs which until now have been controlled by
> >device tree (if at all). If the main question we want to answer is
> >"which clock ref is used to drive internal clock" all we need is a MUX.
> >If we want to make dpll cover also ASIC PLLs for platforms without
> >device tree we need a more generic name than TXC, IMHO.  
> 
> Well, 'floating' MUX type pin not connected to any dpll would require a
> lot of additional implementations, just to allow source selection, as we
> have tried it already.
> 
> Wouldn't more generic name cause a DPLL purpose problem?

The old proposal in netdev family was to to have source selection
without creating a real mux. Not saying I'm dead set on that direction.

> We still want to make sure that given DPLL device would serve the role
> of source selection for particular port where a source pin should be an
> output either on EEC dpll or some external signal generator but somehow
> related to SyncE or similar solutions.

Right, but adding a new "type" per location of the PLL (especially if
we lean into covering any ASIC PLL) may not scale, and opens us up to
"vendor X calls it Y" and "in design A clock is fed by pll type X and
in design B by type Y".

IIUC you do provide "linking" of the pins? netdev will have the MAC pin
assigned. Is the pin that connects the PLLs also annotated so that user
knows what's on the "other side"? Maybe the topology would be clear
enough from just that, and we don't have to add a TXC type.
Call the PLL "integrated" or something generic. User should be able to
trace the path of the signals?

>From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
>Jakub Kicinski
>Sent: Thursday, April 16, 2026 5:28 PM
>
>On Wed, 15 Apr 2026 13:23:22 +0000 Kubalewski, Arkadiusz wrote:
>> >> Well, the true is that we did not anticipated per-port control of the
>> >> TX clock source, as a single DPLL device could drive multiple of
>> >> such.
>> >>
>> >> This is not true, that we pretend there is a second PLL - there is a
>> >> PLL on each TX clock, maybe not a full DPLL, but still the loop with
>> >> a control over it's sources is there and it has the same 2 external
>> >> sources + default XO.
>> >
>> >Don't we put that MAC PLL into bypass mode if we feed a clock from
>> >the EEC DPLL?
>>
>> This HW doesn't use EEC DPLL signal to feed MAC clock, as DPLL is
>> external from NIC point of view. Only 2 signals from such external DPLL
>> device are used by NIC:
>> - synce (a single source for all those TXC per-port DPLL device)
>> - time_ref (a source for the TS_PLL - which drives PTP timer)
>
>No bypass? The PLL is actually in the loop? oof, this is beyond
>my understanding of clocks and signals :S
>

TBH, I am not entirely sure what do you mean with MAC PLL into bypass
mode, but the HW description I have provided is still true, the MAC is
not fed with any DPLL provided signal here. Only port tx clocks PLLs and
a timer PLL can use those.

>> >> A mentioned try of adding per port MUX-type pin, just to give some
>> >> control
>> >> to the user, is where we wanted to simplify things, but in the end
>> >> the
>> >> API
>> >> would have to be modified in significant way, various paths related
>> >> to
>> >> pin
>> >> registration and keeping correct references, just to make working
>> >> case
>> >> for the pin_on_pin_register and it's internals. We decided that the
>> >> burden
>> >> and impact for existing design was to high.
>> >>
>> >> And that is why the TXC approach emerged, the change of DPLL is
>> >> minimal,
>> >> The model is still correct from user perspective, SyncE SW controller
>> >> shall
>> >> anticipate possibility that per-port TXC dpll is there
>> >
>> >We are starting to push into what was previously the domain of
>> >drivers/clk, tho. IIUC the "ASIC PLL"s are usually integrated with
>> >clock dividers. And cannot be "configured" after chip init / async
>> >reset (which is why I presume you whack a reset in patch 7?).
>>
>> Well, we need CGU-dividers change for a frequency-compliance with lower
>> link speeds, the link reset which is required as part of tx-clk switch
>> and link establishment on a new clock.
>>
>> >
>> >> This particular device and driver doesn't implement any EEC-type DPLL
>> >> device, the one could think that we can just change the type here and
>> >> use
>> >> EEC type instead of new one TXC - since we share pins from external
>> >> dpll
>> >> driver, which is EEC type, and our DPLL device would have different
>> >> clock_id
>> >> and module. But, further designs, where a single NIC is having
>> >> control
>> >> over
>> >> both a EEC DPLL and ability to control each source per-port this
>> >> would
>> >> be
>> >> problematic. At least one NIC Port driver would have to have 2 EEC-
>> >> type
>> >> DPLLs
>> >> leaving user with extra confusion.
>> >
>> >The distinction between TXC and EEC dpll is confusing.
>> >I thought EEC one _was_supposed_to_ drive the Tx clock?
>> >What PPS means is obvious, what EEC means if not driving Tx clock is
>> >unclear to me..
>> >
>>
>> Yes, correct, EEC DPLL main task would be to drive TX clocks of NIC
>> ports, but if there is a per-port control something extra is required.
>>
>> >Let me summarize my concerns - we need to navigate the split between
>> >drivers/clk and dpll. We need a distinction on what goes where, because
>> >every ASIC has a bunch of PLLs which until now have been controlled by
>> >device tree (if at all). If the main question we want to answer is
>> >"which clock ref is used to drive internal clock" all we need is a MUX.
>> >If we want to make dpll cover also ASIC PLLs for platforms without
>> >device tree we need a more generic name than TXC, IMHO.
>>
>> Well, 'floating' MUX type pin not connected to any dpll would require a
>> lot of additional implementations, just to allow source selection, as we
>> have tried it already.
>>
>> Wouldn't more generic name cause a DPLL purpose problem?
>
>The old proposal in netdev family was to to have source selection
>without creating a real mux. Not saying I'm dead set on that direction.
>

Yes, correct, it kept the list of dpll pins valid for source selection of
tx clock within the netdev and control over it through RT netlink.
That solution was rather simple but you requested to hack into dpll so we
did here.

IMHO this is cleanest and simplest solution we could find to keep it
within DPLL subsystem.

>> We still want to make sure that given DPLL device would serve the role
>> of source selection for particular port where a source pin should be an
>> output either on EEC dpll or some external signal generator but somehow
>> related to SyncE or similar solutions.
>
>Right, but adding a new "type" per location of the PLL (especially if
>we lean into covering any ASIC PLL) may not scale, and opens us up to
>"vendor X calls it Y" and "in design A clock is fed by pll type X and
>in design B by type Y".
>

I was thinking that this is more like a purpose specific DPLL device, if
someone would want something similar we would have to review it, right?

>IIUC you do provide "linking" of the pins? netdev will have the MAC pin
>assigned. Is the pin that connects the PLLs also annotated so that user
>knows what's on the "other side"? Maybe the topology would be clear
>enough from just that, and we don't have to add a TXC type.
>Call the PLL "integrated" or something generic. User should be able to
>trace the path of the signals?

It depends, TX clock has one of external pins connected to external DPLL,
but second is a board-level pin with ability to provide some external
clock signal, the user would have to determine that purpose just based
on the topology of one of the pins, which seems a bit problematic?
I.e. if at some point there would be HW with only external non-DPLL
connected pins?

I mean 'generic' type is something we could do, but as already mentioned,
thought that we want a DPLL types specified/designed for some particular
functions/tasks. 

Thank you!
Arkadiusz

On Thu, 16 Apr 2026 18:26:11 +0000 Kubalewski, Arkadiusz wrote:
> >> This HW doesn't use EEC DPLL signal to feed MAC clock, as DPLL is
> >> external from NIC point of view. Only 2 signals from such external DPLL
> >> device are used by NIC:
> >> - synce (a single source for all those TXC per-port DPLL device)
> >> - time_ref (a source for the TS_PLL - which drives PTP timer)  
> >
> >No bypass? The PLL is actually in the loop? oof, this is beyond
> >my understanding of clocks and signals :S
>
> TBH, I am not entirely sure what do you mean with MAC PLL into bypass
> mode, but the HW description I have provided is still true, the MAC is
> not fed with any DPLL provided signal here. Only port tx clocks PLLs and
> a timer PLL can use those.

The ASIC PLL IPs I managed to find had a bypass mode where the reference
/ input frequency still goes thru the dividers but the PLL circuit is
bypassed. I assumed that if we want to distribute a syntonized clock
across the network we would want as few PLL circuits in the paths as
possible and we'd use bypass (which would be relevant here since for
the target use case we wouldn't engage the PLL of the TXC). But this 
is 100% guesswork so I'm probably speaking gibberish.

> >> Well, 'floating' MUX type pin not connected to any dpll would require a
> >> lot of additional implementations, just to allow source selection, as we
> >> have tried it already.
> >>
> >> Wouldn't more generic name cause a DPLL purpose problem?  
> >
> >The old proposal in netdev family was to to have source selection
> >without creating a real mux. Not saying I'm dead set on that direction.
> 
> Yes, correct, it kept the list of dpll pins valid for source selection of
> tx clock within the netdev and control over it through RT netlink.
> That solution was rather simple but you requested to hack into dpll so we
> did here.
> 
> IMHO this is cleanest and simplest solution we could find to keep it
> within DPLL subsystem.
> 
> >> We still want to make sure that given DPLL device would serve the role
> >> of source selection for particular port where a source pin should be an
> >> output either on EEC dpll or some external signal generator but somehow
> >> related to SyncE or similar solutions.  
> >
> >Right, but adding a new "type" per location of the PLL (especially if
> >we lean into covering any ASIC PLL) may not scale, and opens us up to
> >"vendor X calls it Y" and "in design A clock is fed by pll type X and
> >in design B by type Y".
> 
> I was thinking that this is more like a purpose specific DPLL device, if
> someone would want something similar we would have to review it, right?

We would if it was a Ethernet MAC PLL, but if someone wanted to expose
whether some random PLL in their ASIC locks - are we adding a new type
for each one of those?

> >IIUC you do provide "linking" of the pins? netdev will have the MAC pin
> >assigned. Is the pin that connects the PLLs also annotated so that user
> >knows what's on the "other side"? Maybe the topology would be clear
> >enough from just that, and we don't have to add a TXC type.
> >Call the PLL "integrated" or something generic. User should be able to
> >trace the path of the signals?  
> 
> It depends, TX clock has one of external pins connected to external DPLL,
> but second is a board-level pin with ability to provide some external
> clock signal, the user would have to determine that purpose just based
> on the topology of one of the pins, which seems a bit problematic?
> I.e. if at some point there would be HW with only external non-DPLL
> connected pins?

Not sure I follow, TBH. To me the function of the "MAC PLL" is fairly
obvious from the fact that it has a pin exposed via rtnetlink. So it's
obviously a DPLL which can drive the Tx clock?

It's the function / relation / linking to the EEC DPLL that may not 
be obvious. But user can see how the pins connect they can get some
LLM to draw a diagram of a live system.. et voila :)

> I mean 'generic' type is something we could do, but as already mentioned,
> thought that we want a DPLL types specified/designed for some particular
> functions/tasks. 

I feel like we often get labels wrong the first time around, so if we
can defer adding them until later that'd make me happy..

>From: Jakub Kicinski <kuba@kernel.org>
>Sent: Friday, April 17, 2026 3:05 AM
>
>On Thu, 16 Apr 2026 18:26:11 +0000 Kubalewski, Arkadiusz wrote:
>> >> This HW doesn't use EEC DPLL signal to feed MAC clock, as DPLL is
>> >> external from NIC point of view. Only 2 signals from such external
>> >> DPLL
>> >> device are used by NIC:
>> >> - synce (a single source for all those TXC per-port DPLL device)
>> >> - time_ref (a source for the TS_PLL - which drives PTP timer)
>> >
>> >No bypass? The PLL is actually in the loop? oof, this is beyond
>> >my understanding of clocks and signals :S
>>
>> TBH, I am not entirely sure what do you mean with MAC PLL into bypass
>> mode, but the HW description I have provided is still true, the MAC is
>> not fed with any DPLL provided signal here. Only port tx clocks PLLs and
>> a timer PLL can use those.
>
>The ASIC PLL IPs I managed to find had a bypass mode where the reference
>/ input frequency still goes thru the dividers but the PLL circuit is
>bypassed. I assumed that if we want to distribute a syntonized clock
>across the network we would want as few PLL circuits in the paths as
>possible and we'd use bypass (which would be relevant here since for
>the target use case we wouldn't engage the PLL of the TXC). But this
>is 100% guesswork so I'm probably speaking gibberish.
>

OK, thanks for explanation. I don't have such details about it, I have
seen only high level design drawings.

>> >> Well, 'floating' MUX type pin not connected to any dpll would require
>> >> a
>> >> lot of additional implementations, just to allow source selection, as
>> >> we
>> >> have tried it already.
>> >>
>> >> Wouldn't more generic name cause a DPLL purpose problem?
>> >
>> >The old proposal in netdev family was to to have source selection
>> >without creating a real mux. Not saying I'm dead set on that direction.
>>
>> Yes, correct, it kept the list of dpll pins valid for source selection
>> of
>> tx clock within the netdev and control over it through RT netlink.
>> That solution was rather simple but you requested to hack into dpll so
>> we
>> did here.
>>
>> IMHO this is cleanest and simplest solution we could find to keep it
>> within DPLL subsystem.
>>
>> >> We still want to make sure that given DPLL device would serve the
>> >> role
>> >> of source selection for particular port where a source pin should be
>> >> an
>> >> output either on EEC dpll or some external signal generator but
>> >> somehow
>> >> related to SyncE or similar solutions.
>> >
>> >Right, but adding a new "type" per location of the PLL (especially if
>> >we lean into covering any ASIC PLL) may not scale, and opens us up to
>> >"vendor X calls it Y" and "in design A clock is fed by pll type X and
>> >in design B by type Y".
>>
>> I was thinking that this is more like a purpose specific DPLL device, if
>> someone would want something similar we would have to review it, right?
>
>We would if it was a Ethernet MAC PLL, but if someone wanted to expose
>whether some random PLL in their ASIC locks - are we adding a new type
>for each one of those?

Yes, that was the implicit intention within those patches, if other purpose
specific PLL would have to be present for whatever HW design and user
control over it would be required, then that would be the easiest to
maintain in the long term? Multiple types and each have own function/purpose.

It would be good as long as there is one PLL for a function per board, once
there could be multiple ones for single function, we would have to add some
enumeration (labels, etc.)

>
>> >IIUC you do provide "linking" of the pins? netdev will have the MAC pin
>> >assigned. Is the pin that connects the PLLs also annotated so that user
>> >knows what's on the "other side"? Maybe the topology would be clear
>> >enough from just that, and we don't have to add a TXC type.
>> >Call the PLL "integrated" or something generic. User should be able to
>> >trace the path of the signals?
>>
>> It depends, TX clock has one of external pins connected to external
>> DPLL,
>> but second is a board-level pin with ability to provide some external
>> clock signal, the user would have to determine that purpose just based
>> on the topology of one of the pins, which seems a bit problematic?
>> I.e. if at some point there would be HW with only external non-DPLL
>> connected pins?
>
>Not sure I follow, TBH. To me the function of the "MAC PLL" is fairly
>obvious from the fact that it has a pin exposed via rtnetlink. So it's
>obviously a DPLL which can drive the Tx clock?
>

I am lost a bit now too. You mean clock recovery pin? And EEC type dpll?
In this solution the 'MAC'/EEC is external and it doesn't drive TX clocks
directly.

>It's the function / relation / linking to the EEC DPLL that may not
>be obvious. But user can see how the pins connect they can get some
>LLM to draw a diagram of a live system.. et voila :)
>

Yes, correct it would work for this particular HW, but adding a variant
without a external EEC-connected pin in the picture would be problematic
to understand 'generic' dpll purpose, pointing to the labels later.

Just to make it clear. I believe that generic type dpll could be used in
any HW and for any purpose, so after all each such usage could possibly
introduce entropy and confusion on the user side.

But if you are fine with that, then sure, we can live with generic
purpose dpll.

>> I mean 'generic' type is something we could do, but as already
>> mentioned,
>> thought that we want a DPLL types specified/designed for some particular
>> functions/tasks.
>
>I feel like we often get labels wrong the first time around, so if we
>can defer adding them until later that'd make me happy..

Sure something like it later would be required.

Thank you!
Arkadiusz

On Fri, 17 Apr 2026 12:22:05 +0000 Kubalewski, Arkadiusz wrote:
> >> I was thinking that this is more like a purpose specific DPLL device, if
> >> someone would want something similar we would have to review it, right?  
> >
> >We would if it was a Ethernet MAC PLL, but if someone wanted to expose
> >whether some random PLL in their ASIC locks - are we adding a new type
> >for each one of those?  
> 
> Yes, that was the implicit intention within those patches, if other purpose
> specific PLL would have to be present for whatever HW design and user
> control over it would be required, then that would be the easiest to
> maintain in the long term? Multiple types and each have own function/purpose.
> 
> It would be good as long as there is one PLL for a function per board, once
> there could be multiple ones for single function, we would have to add some
> enumeration (labels, etc.)

Defer on adding identifiers. User knows which driver and bus device
spawned the pll and more importantly what the pin topology is.
Naming in the kernel is rarely a good idea.

> >> It depends, TX clock has one of external pins connected to external
> >> DPLL,
> >> but second is a board-level pin with ability to provide some external
> >> clock signal, the user would have to determine that purpose just based
> >> on the topology of one of the pins, which seems a bit problematic?
> >> I.e. if at some point there would be HW with only external non-DPLL
> >> connected pins?  
> >
> >Not sure I follow, TBH. To me the function of the "MAC PLL" is fairly
> >obvious from the fact that it has a pin exposed via rtnetlink. So it's
> >obviously a DPLL which can drive the Tx clock?
> 
> I am lost a bit now too. You mean clock recovery pin? And EEC type dpll?
> In this solution the 'MAC'/EEC is external and it doesn't drive TX clocks
> directly.

MAC == "tspll" == TXC in this series. On Grzegorz's diagram the new PLL
was in the MAC, which makes sense since it's a pll in the same ASIC as
the MAC.

I'm saying that the function of that pll is obvious since its pin will
plug into the netdev / rtnetlink.

> >It's the function / relation / linking to the EEC DPLL that may not
> >be obvious. But user can see how the pins connect they can get some
> >LLM to draw a diagram of a live system.. et voila :)
> 
> Yes, correct it would work for this particular HW, but adding a variant
> without a external EEC-connected pin in the picture would be problematic
> to understand 'generic' dpll purpose, pointing to the labels later.

The function of the "MAC/tspll" is still obvious. The clarity of the
external PLL is not helped by naming the "MAC/tspll".

> Just to make it clear. I believe that generic type dpll could be used in
> any HW and for any purpose, so after all each such usage could possibly
> introduce entropy and confusion on the user side.
> 
> But if you are fine with that, then sure, we can live with generic
> purpose dpll.

Considering all the imperfect options - generic / unnamed type would be
my preference.

>From: Jakub Kicinski <kuba@kernel.org>
>Sent: Saturday, April 18, 2026 9:26 PM
>
>On Fri, 17 Apr 2026 12:22:05 +0000 Kubalewski, Arkadiusz wrote:
>> >> I was thinking that this is more like a purpose specific DPLL device,
>> >> if
>> >> someone would want something similar we would have to review it,
>> >> right?
>> >
>> >We would if it was a Ethernet MAC PLL, but if someone wanted to expose
>> >whether some random PLL in their ASIC locks - are we adding a new type
>> >for each one of those?
>>
>> Yes, that was the implicit intention within those patches, if other
>> purpose
>> specific PLL would have to be present for whatever HW design and user
>> control over it would be required, then that would be the easiest to
>> maintain in the long term? Multiple types and each have own
>> function/purpose.
>>
>> It would be good as long as there is one PLL for a function per board,
>> once
>> there could be multiple ones for single function, we would have to add
>> some
>> enumeration (labels, etc.)
>
>Defer on adding identifiers. User knows which driver and bus device
>spawned the pll and more importantly what the pin topology is.
>Naming in the kernel is rarely a good idea.

Sure.

>
>> >> It depends, TX clock has one of external pins connected to external
>> >> DPLL,
>> >> but second is a board-level pin with ability to provide some external
>> >> clock signal, the user would have to determine that purpose just
>> >> based
>> >> on the topology of one of the pins, which seems a bit problematic?
>> >> I.e. if at some point there would be HW with only external non-DPLL
>> >> connected pins?
>> >
>> >Not sure I follow, TBH. To me the function of the "MAC PLL" is fairly
>> >obvious from the fact that it has a pin exposed via rtnetlink. So it's
>> >obviously a DPLL which can drive the Tx clock?
>>
>> I am lost a bit now too. You mean clock recovery pin? And EEC type dpll?
>> In this solution the 'MAC'/EEC is external and it doesn't drive TX
>> clocks
>> directly.
>
>MAC == "tspll" == TXC in this series. On Grzegorz's diagram the new PLL
>was in the MAC, which makes sense since it's a pll in the same ASIC as
>the MAC.
>

We wanted the TSPLL from the picture to be PPS type as it drives the PHC
timer within the MAC.

>I'm saying that the function of that pll is obvious since its pin will
>plug into the netdev / rtnetlink.
>

Yeah I got it, just saying it will work for now :)

>> >It's the function / relation / linking to the EEC DPLL that may not
>> >be obvious. But user can see how the pins connect they can get some
>> >LLM to draw a diagram of a live system.. et voila :)
>>
>> Yes, correct it would work for this particular HW, but adding a variant
>> without a external EEC-connected pin in the picture would be problematic
>> to understand 'generic' dpll purpose, pointing to the labels later.
>
>The function of the "MAC/tspll" is still obvious. The clarity of the
>external PLL is not helped by naming the "MAC/tspll".
>
>> Just to make it clear. I believe that generic type dpll could be used in
>> any HW and for any purpose, so after all each such usage could possibly
>> introduce entropy and confusion on the user side.
>>
>> But if you are fine with that, then sure, we can live with generic
>> purpose dpll.
>
>Considering all the imperfect options - generic / unnamed type would be
>my preference.

Ok, sounds good.

Thank you!
Arkadiusz

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Kubalewski, Arkadiusz
> Sent: Monday, April 20, 2026 4:52 PM
> To: Jakub Kicinski <kuba@kernel.org>
> Cc: Vecera, Ivan <ivecera@redhat.com>; vadim.fedorenko@linux.dev;
> edumazet@google.com; netdev@vger.kernel.org;
> richardcochran@gmail.com; donald.hunter@gmail.com; linux-
> kernel@vger.kernel.org; davem@davemloft.net;
> Prathosh.Satish@microchip.com; andrew+netdev@lunn.ch; intel-wired-
> lan@lists.osuosl.org; horms@kernel.org; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; pabeni@redhat.com; jiri@resnulli.us
> Subject: Re: [Intel-wired-lan] [PATCH v5 net-next 0/8] dpll/ice: Add TXC DPLL
> type and full TX reference clock control for E825
> 
> >From: Jakub Kicinski <kuba@kernel.org>
> >Sent: Saturday, April 18, 2026 9:26 PM
> >
> >On Fri, 17 Apr 2026 12:22:05 +0000 Kubalewski, Arkadiusz wrote:
> >> >> I was thinking that this is more like a purpose specific DPLL device,
> >> >> if
> >> >> someone would want something similar we would have to review it,
> >> >> right?
> >> >
> >> >We would if it was a Ethernet MAC PLL, but if someone wanted to expose
> >> >whether some random PLL in their ASIC locks - are we adding a new type
> >> >for each one of those?
> >>
> >> Yes, that was the implicit intention within those patches, if other
> >> purpose
> >> specific PLL would have to be present for whatever HW design and user
> >> control over it would be required, then that would be the easiest to
> >> maintain in the long term? Multiple types and each have own
> >> function/purpose.
> >>
> >> It would be good as long as there is one PLL for a function per board,
> >> once
> >> there could be multiple ones for single function, we would have to add
> >> some
> >> enumeration (labels, etc.)
> >
> >Defer on adding identifiers. User knows which driver and bus device
> >spawned the pll and more importantly what the pin topology is.
> >Naming in the kernel is rarely a good idea.
> 
> Sure.
> 
> >
> >> >> It depends, TX clock has one of external pins connected to external
> >> >> DPLL,
> >> >> but second is a board-level pin with ability to provide some external
> >> >> clock signal, the user would have to determine that purpose just
> >> >> based
> >> >> on the topology of one of the pins, which seems a bit problematic?
> >> >> I.e. if at some point there would be HW with only external non-DPLL
> >> >> connected pins?
> >> >
> >> >Not sure I follow, TBH. To me the function of the "MAC PLL" is fairly
> >> >obvious from the fact that it has a pin exposed via rtnetlink. So it's
> >> >obviously a DPLL which can drive the Tx clock?
> >>
> >> I am lost a bit now too. You mean clock recovery pin? And EEC type dpll?
> >> In this solution the 'MAC'/EEC is external and it doesn't drive TX
> >> clocks
> >> directly.
> >
> >MAC == "tspll" == TXC in this series. On Grzegorz's diagram the new PLL
> >was in the MAC, which makes sense since it's a pll in the same ASIC as
> >the MAC.
> >
> 
> We wanted the TSPLL from the picture to be PPS type as it drives the PHC
> timer within the MAC.
> 
> >I'm saying that the function of that pll is obvious since its pin will
> >plug into the netdev / rtnetlink.
> >
> 
> Yeah I got it, just saying it will work for now :)
> 
> >> >It's the function / relation / linking to the EEC DPLL that may not
> >> >be obvious. But user can see how the pins connect they can get some
> >> >LLM to draw a diagram of a live system.. et voila :)
> >>
> >> Yes, correct it would work for this particular HW, but adding a variant
> >> without a external EEC-connected pin in the picture would be problematic
> >> to understand 'generic' dpll purpose, pointing to the labels later.
> >
> >The function of the "MAC/tspll" is still obvious. The clarity of the
> >external PLL is not helped by naming the "MAC/tspll".
> >
> >> Just to make it clear. I believe that generic type dpll could be used in
> >> any HW and for any purpose, so after all each such usage could possibly
> >> introduce entropy and confusion on the user side.
> >>
> >> But if you are fine with that, then sure, we can live with generic
> >> purpose dpll.
> >
> >Considering all the imperfect options - generic / unnamed type would be
> >my preference.
> 
> Ok, sounds good.
> 
> Thank you!
> Arkadiusz

Thanks for the fruitful discussion. Just submitted v7 in which DPLL_TYPE_GENERIC
Has been introduced (instead of DPLL_TYPE_TXC).

Regards

Grzegorz

On Mon, 13 Apr 2026 08:19:30 +0000 Kubalewski, Arkadiusz wrote:
> >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 :(  
> 
> Well, the true is that we did not anticipated per-port control of the
> TX clock source, as a single DPLL device could drive multiple of such.
> 
> This is not true, that we pretend there is a second PLL - there is a
> PLL on each TX clock, maybe not a full DPLL, but still the loop with
> a control over it's sources is there and it has the same 2 external
> sources + default XO.

Let me dig around and see if I can find any docs for PLL IPs
that get integrated into ASICs. The DPLL subsystem has implicitly
focused on standalone, timing related PLLs. Every ASIC out there 
has a bunch of PLLs to generate the clock signals. It's not clear
to me that DPLL subsystem is the right fit for this. Ping me if
I don't get back to this by the end of the week please. I'll need
to wrap up net-next and send the PR first..

> A mentioned try of adding per port MUX-type pin, just to give some control
> to the user, is where we wanted to simplify things, but in the end the API
> would have to be modified in significant way, various paths related to pin
> registration and keeping correct references, just to make working case
> for the pin_on_pin_register and it's internals. We decided that the burden
> and impact for existing design was to high.
> 
> And that is why the TXC approach emerged, the change of DPLL is minimal,
> The model is still correct from user perspective, SyncE SW controller shall
> anticipate possibility that per-port TXC dpll is there 
> 
> This particular device and driver doesn't implement any EEC-type DPLL
> device, the one could think that we can just change the type here and use
> EEC type instead of new one TXC - since we share pins from external dpll
> driver, which is EEC type, and our DPLL device would have different clock_id
> and module. But, further designs, where a single NIC is having control over
> both a EEC DPLL and ability to control each source per-port this would be
> problematic. At least one NIC Port driver would have to have 2 EEC-type DPLLs
> leaving user with extra confusion.