On December 12, 2025 11:20:43 AM GMT+01:00, "Loktionov, Aleksandr"
wrote:
>
>
>> -Original Message-
>> From: Intel-wired-lan On Behalf
>> Of Ivan Vecera
>> Sent: Thursday, December 11, 2025 8:48 PM
>> To: [email protected]; Andrew Lunn ;
>> David S. Miller ; Eric Dumazet
>> ; Jakub Kicinski ; Paolo Abeni
>> ; Rob Herring ; Krzysztof
>> Kozlowski ; Conor Dooley ;
>> Vadim Fedorenko ; Kubalewski, Arkadiusz
>> ; Nitka, Grzegorz
>> ; Jiri Pirko ; Oros,
>> Petr ; Schmidt, Michal ;
>> Prathosh Satish ; Nguyen, Anthony L
>> ; Kitszel, Przemyslaw
>> ; Saeed Mahameed ;
>> Leon Romanovsky ; Tariq Toukan ;
>> Mark Bloch ; Richard Cochran
>> ; Jonathan Lemon
>> ; Simon Horman ;
>> Lobakin, Aleksander ; Willem de Bruijn
>> ; Stefan Wahren ;
>> [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
>>
>> 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
>> Co-developed-by: Grzegorz Nitka
>> Signed-off-by: Ivan Vecera
>> Signed-off-by: Grzegorz Nitka
>> Signed-off-by: Arkadiusz Kubalewski
>> ---
>> 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
>
