On December 12, 2025 11:20:43 AM GMT+01:00, "Loktionov, Aleksandr"
<[email protected]> wrote:
>
>
>> -----Original Message-----
>> From: Intel-wired-lan <[email protected]> On Behalf
>> Of Ivan Vecera
>> Sent: Thursday, December 11, 2025 8:48 PM
>> To: [email protected]; Andrew Lunn <[email protected]>;
>> David S. Miller <[email protected]>; Eric Dumazet
>> <[email protected]>; Jakub Kicinski <[email protected]>; Paolo Abeni
>> <[email protected]>; Rob Herring <[email protected]>; Krzysztof
>> Kozlowski <[email protected]>; Conor Dooley <[email protected]>;
>> Vadim Fedorenko <[email protected]>; Kubalewski, Arkadiusz
>> <[email protected]>; Nitka, Grzegorz
>> <[email protected]>; Jiri Pirko <[email protected]>; Oros,
>> Petr <[email protected]>; Schmidt, Michal <[email protected]>;
>> Prathosh Satish <[email protected]>; Nguyen, Anthony L
>> <[email protected]>; Kitszel, Przemyslaw
>> <[email protected]>; Saeed Mahameed <[email protected]>;
>> Leon Romanovsky <[email protected]>; Tariq Toukan <[email protected]>;
>> Mark Bloch <[email protected]>; Richard Cochran
>> <[email protected]>; Jonathan Lemon
>> <[email protected]>; Simon Horman <[email protected]>;
>> Lobakin, Aleksander <[email protected]>; Willem de Bruijn
>> <[email protected]>; Stefan Wahren <[email protected]>;
>> [email protected]; [email protected]; intel-
>> [email protected]; [email protected]
>> Subject: [Intel-wired-lan] [PATCH RFC net-next 13/13] ice: dpll:
>> Support E825-C SyncE and dynamic pin discovery
>>
>> From: Arkadiusz Kubalewski <[email protected]>
>>
>> Add DPLL support for the Intel E825-C Ethernet controller. Unlike
>> previous
>> generations (E810), the E825-C connects to the platform's DPLL
>> subsystem
>> via MUX pins defined in the system firmware (Device Tree/ACPI).
>>
>> Implement the following mechanisms to support this architecture:
>>
>> 1. Dynamic Pin Discovery: Use the fwnode_dpll_pin_find() helper to
>> locate the parent MUX pins defined in the firmware.
>>
>> 2. Asynchronous Registration: Since the platform DPLL driver may
>> probe
>> independently of the network driver, utilize the DPLL notifier
>> chain
>> (register_dpll_notifier). The driver listens for DPLL_PIN_CREATED
>> events to detect when the parent MUX pins become available, then
>> registers its own Recovered Clock (RCLK) and PTP (1588) pins as
>> children
>> of those parents.
>>
>> 3. Hardware Configuration: Implement the specific register access
>> logic
>> for E825-C CGU (Clock Generation Unit) registers (R10, R11). This
>> includes configuring the bypass MUXes and clock dividers required
>> to
>> drive SyncE and PTP signals.
>>
>> 4. Split Initialization: Refactor `ice_dpll_init()` to separate the
>> static initialization path of E810 from the dynamic, firmware-
>> driven
>> path required for E825-C.
>>
>> Co-developed-by: Ivan Vecera <[email protected]>
>> Co-developed-by: Grzegorz Nitka <[email protected]>
>> Signed-off-by: Ivan Vecera <[email protected]>
>> Signed-off-by: Grzegorz Nitka <[email protected]>
>> Signed-off-by: Arkadiusz Kubalewski <[email protected]>
>> ---
>> drivers/net/ethernet/intel/ice/ice_dpll.c | 964
>> ++++++++++++++++++--
>> drivers/net/ethernet/intel/ice/ice_dpll.h | 29 +
>> drivers/net/ethernet/intel/ice/ice_lib.c | 3 +
>> drivers/net/ethernet/intel/ice/ice_ptp.c | 29 +
>> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 9 +-
>> drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 1 +
>> drivers/net/ethernet/intel/ice/ice_tspll.c | 223 +++++
>> drivers/net/ethernet/intel/ice/ice_tspll.h | 14 +-
>> drivers/net/ethernet/intel/ice/ice_type.h | 6 +
>> 9 files changed, 1188 insertions(+), 90 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c
>
>...
>
>> +static int
>> +ice_dpll_pin_get_parent_num(struct ice_dpll_pin *pin,
>> + const struct dpll_pin *parent)
>> +{
>> + int i;
>> +
>> + for (i = 0; pin->num_parents; i++)
>> + if (pin->pf->dplls.inputs[pin->parent_idx[i]].pin ==
>> parent)
>Oh, no! we don't need a 2nd Infinite Loop in Cupertino!
Oops, thanks for pointing out... During testing the parent
was always found so this didn't cause any problem.
Of course I will fix it. 😉
>
>...
>
>
>> --
>> 2.51.2
>
