linux-kernel - 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: <IA1PR11MB621913F389165EE4D7CCFF2D9284A@IA1PR11MB6219.namprd11.prod.outlook.com>
Date: Wed, 7 Jan 2026 21:33:06 +0000
From: "Nitka, Grzegorz" <grzegorz.nitka@...el.com>
To: "Grinberg, Vitaly" <vgrinber@...hat.com>
CC: "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>, "Nguyen, Anthony
 L" <anthony.l.nguyen@...el.com>, "Kubalewski, Arkadiusz"
	<arkadiusz.kubalewski@...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

> -----Original Message-----
> From: Vitaly Grinberg <vgrinber@...hat.com>
> Sent: Tuesday, December 16, 2025 3:42 PM
> To: Nitka, Grzegorz <grzegorz.nitka@...el.com>
> Cc: Loktionov, Aleksandr <aleksandr.loktionov@...el.com>; Nguyen,
> Anthony L <anthony.l.nguyen@...el.com>; Kubalewski, Arkadiusz
> <arkadiusz.kubalewski@...el.com>; horms@...nel.org; intel-wired-
> lan@...ts.osuosl.org; linux-doc@...r.kernel.org; linux-
> kernel@...r.kernel.org; netdev@...r.kernel.org;
> pmenzel@...gen.mpg.de; Kitszel, Przemyslaw
> <przemyslaw.kitszel@...el.com>
> Subject: Re:[Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for
> unmanaged DPLL on E830 NIC
> 
> Will a notification be provided when the lock is re-acquired?
> 

Hi Vitaly, thanks for your comments.
We discussed it offline already, but I think I need more clarifications.

Regarding above question ... yes, 'lock' recovery shall be reported in the same way.
Maybe the name of health status is a little bit misleading (ICE_AQC_HEALTH_STATUS_INFO_LOSS_OF_LOCK),
However health_info struct contains the current lock status (either 'locked' or 'unlocked').

> Another concern is the absence of periodical pin notifications. With the E810,
> users received the active pin notifications every 1 second. However, the
> unmanaged DPLL appears to lack this functionality. User implementations
> currently rely on these periodical notifications to derive the overall clock
> state, metrics and events from the phase offset. It seems that unmanaged
> DPLL users will be forced to support two distinct types of DPLLs: one that
> sends periodical pin notifications and one that does not. Crucially, this
> difference does not appear to be reflected in the device capabilities,
> meaning users cannot know in advance whether to expect these
> notifications.

After reading it one more time, I'm not sure if I get it right in the first place.
With this patch implementation, there is dpll change notification applied.
By dpll notification I mean calling dpll_device_change_ntf function.
Isn't it what you're looking for?
Notification is triggered only in case when lock status has changed.
It's unmanaged DPLL so the implementation is a little bit simplified, based on FW notification.
There is no need for polling thread like it's done for E810.
But even in case of E810, where polling is applied (2 samples per second), notification is triggered only in case of
dpll/pin status change, not every 1 second.
So please clarify, so either I don't understand the question (please note, I'm only covering the main author)
or notification mechanism, at least about dpll lock state, is already implemented.