netdev - RE: Re:[Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for unmanaged DPLL on E830 NIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <LV4PR11MB9491B0E591D66E4AEDE9B1329B8FA@LV4PR11MB9491.namprd11.prod.outlook.com>
Date: Wed, 14 Jan 2026 13:32:33 +0000
From: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
To: "Grinberg, Vitaly" <vgrinber@...hat.com>
CC: "Nitka, Grzegorz" <grzegorz.nitka@...el.com>, "Loktionov, Aleksandr"
	<aleksandr.loktionov@...el.com>, "Nguyen, Anthony L"
	<anthony.l.nguyen@...el.com>, "horms@...nel.org" <horms@...nel.org>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "pmenzel@...gen.mpg.de"
	<pmenzel@...gen.mpg.de>, "Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>
Subject: RE: Re:[Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for
 unmanaged DPLL on E830 NIC

>From: Vitaly Grinberg <vgrinber@...hat.com>
>Sent: Wednesday, January 14, 2026 12:39 PM
>

[..]

>> >
>> >I see a few challenges for the user here. The biggest one is that the
>> >application can't tell the difference between a device that will report
>> >phase offsets and this unmanaged device that never will.
>> >A possible way forward would be adding a capability flag to the DPLL API
>> >so
>> >users don't have to guess.
>>
>> There is no phase-offset field as pointed in the above example.
>> No 'phase-offset' attribute -> no such capability.
>> Why isn’t that enough?
>
>Pin reply does not contain phase offset, so no change notifications
>are expected?
>Could there be devices that don't report phase offset, but report state
>changes?
>Is this the intended use of the phase offset API to be interpreted as
>a general pin
>notification capability flag?
>

Sorry, this is not what I meant.

The E810 produces notifications not only for the pin's phase offset but
also for other pin attribute changes. When it comes to the E810 pins,
notifications generated by phase offset changes are quite frequent.
However, it wasn't intention to produce them every second; this is simply
the result of frequent phase offset changes.

Typically, the pin state changes for the pin, but for E830, the unmanaged
mode means that the state of the pin never changes, resulting in no pin
notifications being produced in the end.

Hope that clears things up.

>>
>> >However, the preferred solution would be to simply mirror the E810
>> >behavior
>> >(sending phase offset). This preserves the existing API contract and
>> >prevents users, who have already built applications for this interface,
>> >from needing to implement special handling for a new hardware variant
>> >that
>> >behaves differently.
>>
>> This is not currently possible from driver perspective.
>> We miss the FW API for it.
>>
>> >There are additional inconsistencies in the existing structure I wanted
>> >to
>> >bring to your attention.
>> >1. I'm not entirely sure how a 1588-TIME_SYNC pin can have a parent
>> >device
>> >of type "eec". EEC is all about frequency synchronization, and yet the
>> >pin
>> >named 1588-TIME_SYNC is clearly a phase pin. This also doesn't play well
>> >with existing implementations, where EEC circuits deal with frequency,
>> >PPS
>> >circuits deal with phase, and there is clear distinction between the two
>> >with regard to the meaning of "being locked".
>>
>> This dpll device type was established based on the main purpose of dpll
>> device which is to drive the network ports phy clocks with it.
>
>What is the physical meaning of this indication (lock-status':
>'locked')? Locked on what?

Lock status is dpll device property.

But full picture has to be determined from the list of pins, for this
particular case, one input provided from host through pci-e pin, 10MHz
bandwidth frequency and 1 PPS sync pulses.

As already pointed the type of dpll shall let user know the purpose of
the dpll existence instead of particular input properties.
Input properties are determined with the pin's attributes.

>As a user of this circuit I want to know that the device is locked on
>the phase of the input signal with a certain precision.
>Is this the meaning of "locked" here? Can an EEC device be locked on
>the Phase of the input signal?

Well I don't have any data on the precision of such, but AFAIK it can.
EEC dpll shall be producing stable signal, the input it uses is only
part of the full dpll device picture.

>Users of other devices (e810, zl3073x) may have implemented logic to
>determine the phase lock by
>enforcing the pin parent device type as PPS. How should they change it
>to determine phase lock (and why)?
>

I am Sorry, I don't understand the example above, could you please
Elaborate on details of such setup?

Thank you!
Arkadiusz

>>
>> >2. Since it is also an external embedded sync input pin, could it be
>> >possible to expose this information and include `esync-frequency` and
>> >`esync-pulse`? That could be useful for configuring the leading DPLL
>> >that
>> >drives the unmanaged one.
>>
>> Sure, esync caps should be provided, as the commit message example shown:
>> +    'esync-frequency': 1,
>> +    'esync-frequency-supported': [{'frequency-max': 1, 'frequency-min':
>>1}],
>> +    'esync-pulse': 25,
>>
>
>Oh, I must have missed that.
>Thanks!
>Vitaly
>
>> Thank you!
>> Arkadiusz