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

[Carolina Jubran <cjubran@nvidia.com>]

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