linux-kernel - Re: [PATCH net-next] dpll: zl3073x: Allow to use custom phase measure averaging factor

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: <5ca46c45-96c3-4ad8-b00a-2494ae12d88b@linux.dev>
Date: Wed, 10 Sep 2025 13:34:16 +0100
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Ivan Vecera <ivecera@...hat.com>, netdev@...r.kernel.org
Cc: Prathosh Satish <Prathosh.Satish@...rochip.com>,
 Jiri Pirko <jiri@...nulli.us>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 Jonathan Corbet <corbet@....net>,
 "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
 open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next] dpll: zl3073x: Allow to use custom phase measure
 averaging factor

On 10.09.2025 11:32, Ivan Vecera wrote:
> The DPLL phase measurement block uses an exponential moving average,
> calculated using the following equation:
> 
>                         2^N - 1                1
> curr_avg = prev_avg * --------- + new_val * -----
>                           2^N                 2^N
> 
> Where curr_avg is phase offset reported by the firmware to the driver,
> prev_avg is previous averaged value and new_val is currently measured
> value for particular reference.
> 
> New measurements are taken approximately 40 Hz or at the frequency of
> the reference (whichever is lower).
> 
> The driver currently uses the averaging factor N=2 which prioritizes
> a fast response time to track dynamic changes in the phase. But for
> applications requiring a very stable and precise reading of the average
> phase offset, and where rapid changes are not expected, a higher factor
> would be appropriate.
> 
> Add devlink device parameter phase_offset_avg_factor to allow a user
> set tune the averaging factor via devlink interface.
> 
> Tested-by: Prathosh Satish <Prathosh.Satish@...rochip.com>
> Signed-off-by: Ivan Vecera <ivecera@...hat.com>

[...]

> +static int
> +zl3073x_devlink_param_phase_avg_factor_set(struct devlink *devlink, u32 id,
> +					   struct devlink_param_gset_ctx *ctx,
> +					   struct netlink_ext_ack *extack)
> +{
> +	struct zl3073x_dev *zldev = devlink_priv(devlink);
> +	u8 avg_factor, dpll_meas_ctrl;
> +	int rc;
> +
> +	/* Read DPLL phase measurement control register */
> +	rc = zl3073x_read_u8(zldev, ZL_REG_DPLL_MEAS_CTRL, &dpll_meas_ctrl);
> +	if (rc)
> +		return rc;
> +
> +	/* Convert requested factor to register value */
> +	if (ctx->val.vu8 < 15)
> +		avg_factor = ctx->val.vu8 + 1;
> +	else
> +		avg_factor = 0;
> +

This looks like avg_factor = (ctx->val.vu8 + 1) & 0x0f;
The same logic can be applied for get() function assuming we are aware of
unsigned roll-over...