netdev - Re: [patch net-next 0/3] dpll: expose fractional frequency offset value to user

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] [day] [month] [year] [list]

Message-ID: <ZZhB_vWTb3VZGWBK@nanopsycho>
Date: Fri, 5 Jan 2024 18:53:02 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: netdev@...r.kernel.org, kuba@...nel.org, pabeni@...hat.com,
	davem@...emloft.net, edumazet@...gle.com,
	arkadiusz.kubalewski@...el.com, saeedm@...dia.com, leon@...nel.org,
	michal.michalik@...el.com, rrameshbabu@...dia.com
Subject: Re: [patch net-next 0/3] dpll: expose fractional frequency offset
 value to user

Fri, Jan 05, 2024 at 12:44:23PM CET, vadim.fedorenko@...ux.dev wrote:
>On 03/01/2024 13:28, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@...dia.com>
>> 
>> Allow to expose pin fractional frequency offset value over new DPLL
>> generic netlink attribute. Add an op to get the value from the driver.
>> Implement this new op in mlx5 driver.
>> 
>> Jiri Pirko (3):
>>    dpll: expose fractional frequency offset value to user
>>    net/mlx5: DPLL, Use struct to get values from
>>      mlx5_dpll_synce_status_get()
>>    net/mlx5: DPLL, Implement fractional frequency offset get pin op
>> 
>>   Documentation/netlink/specs/dpll.yaml         | 11 +++
>>   drivers/dpll/dpll_netlink.c                   | 24 +++++
>>   .../net/ethernet/mellanox/mlx5/core/dpll.c    | 94 ++++++++++++-------
>>   include/linux/dpll.h                          |  3 +
>>   include/uapi/linux/dpll.h                     |  1 +
>>   5 files changed, 98 insertions(+), 35 deletions(-)
>> 
>
>Interesting attribute, it's good that hardware can expose this info.
>
>Did you think about building some monitoring/alerts based on it?

The deamon we use internally just exposes this to user mainly for
debugging purposes now. Not sure about another plans with this.


>
>For the series (I'm not sure if it's enough for mlx5, but the
>refactoring looks nice):
>
>Acked-By: Vadim Fedorenko <vadim.fedorenko@...ux.dev>