[PATCH net] net/mlx5: DPLL, fix fractional frequency offset scaling

[PATCH net] net/mlx5: DPLL, fix fractional frequency offset scaling

[Tariq Toukan]

From: Carolina Jubran <cjubran@nvidia.com>

The frequency_diff is reported by firmware in parts-per-trillion, which
is exactly what the DPLL core now expects from the ffo_get callback.

Commit bc443c253fcd ("dpll: expose fractional frequency offset in ppt")
switched the callback contract to ppt but assumed frequency_diff was in
ppm and scaled it by 1000000 to "convert" it. Since the value was
already ppt, this makes both exported attributes wrong.

Report frequency_diff as is and let the core divide it down for the
legacy ppm attribute.

Fixes: f035dca34ede ("net/mlx5: DPLL, Implement fractional frequency offset get pin op")
Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/dpll.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/dpll.c b/drivers/net/ethernet/mellanox/mlx5/core/dpll.c
index 7c69d9029bfa..54ba7c330d66 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/dpll.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/dpll.c
@@ -138,7 +138,7 @@ mlx5_dpll_pin_ffo_get(struct mlx5_dpll_synce_status *synce_status,
 {
 	if (!synce_status->oper_freq_measure)
 		return -ENODATA;
-	*ffo = 1000000LL * synce_status->frequency_diff;
+	*ffo = synce_status->frequency_diff;
 	return 0;
 }
 

base-commit: af32da41b0327b9c6a37856ba82b6760d6c8d10e
-- 
2.44.0

Re: [PATCH net] net/mlx5: DPLL, fix fractional frequency offset scaling

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] net/mlx5: DPLL, fix fractional frequency offset scaling

[sashiko-bot]

> From: Carolina Jubran <cjubran@nvidia.com>
> 
> The frequency_diff is reported by firmware in parts-per-trillion, which
> is exactly what the DPLL core now expects from the ffo_get callback.
> 
> Commit bc443c253fcd ("dpll: expose fractional frequency offset in ppt")
> switched the callback contract to ppt but assumed frequency_diff was in
> ppm and scaled it by 1000000 to "convert" it. Since the value was
> already ppt, this makes both exported attributes wrong.
> 
> Report frequency_diff as is and let the core divide it down for the
> legacy ppm attribute.
> 
> Fixes: f035dca34ede ("net/mlx5: DPLL, Implement fractional frequency offset get pin op")
> Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
> Reviewed-by: Jiri Pirko <jiri@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015074035.1092340-1-tariqt@nvidia.com?part=1

Re: [PATCH net] net/mlx5: DPLL, fix fractional frequency offset scaling

[Carolina Jubran]

On 15/10/2026 10:43, netdev-bot+sinfo@kernel.org wrote:
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>   - How the issue was discovered, e.g. hit in production, hit during
>     development, syzbot report, manual code inspection, LLM or static
>     analysis tool scan.
>
>   - Whether the issue was actually triggered, or is only theoretical
>     (e.g. found by code inspection). If it was triggered please include
>     the symptoms, like the stack trace or error messages.
>
>   - What hardware the change was tested on. For driver fixes please
>     mention the device (and if relevant firmware version) used for
>     testing, or say that the change was not tested on real hardware.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.


Hi,

The issue was found while testing the latest mlx5 driver on an older
kernel that does not support
DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT.

There was no crash or kernel warning. Just that the legacy
DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET attribute reported an incorrect
FFO value.

The mlx5 firmware reports frequency_diff in ppt. Although the legacy
attribute is documented in ppm, our userspace application has always
expected the value exported by mlx5 to be in ppt.

On newer kernels, the driver multiplies the firmware value by 1,000,000
to account for the corresponding division performed by the DPLL core
when exporting the legacy attribute. Older kernels do not perform this
division and expose the scaled value directly, resulting in an FFO value
1,000,000 times too large.

The change was tested on CX6Dx, and the reported FFO value was verified
through both the DPLL netlink interface and our userspace application.

Thanks,
Carolina

Re: [PATCH net] net/mlx5: DPLL, fix fractional frequency offset scaling

[Daniel Machon]

> From: Carolina Jubran <cjubran@nvidia.com>
> 
> The frequency_diff is reported by firmware in parts-per-trillion, which
> is exactly what the DPLL core now expects from the ffo_get callback.
> 
> Commit bc443c253fcd ("dpll: expose fractional frequency offset in ppt")
> switched the callback contract to ppt but assumed frequency_diff was in
> ppm and scaled it by 1000000 to "convert" it. Since the value was
> already ppt, this makes both exported attributes wrong.
> 
> Report frequency_diff as is and let the core divide it down for the
> legacy ppm attribute.

Reviewed-by: Daniel Machon <daniel.machon@microchip.com>