dpll: do not truncate the requested pin frequency before checking it

DPLL_A_PIN_FREQUENCY is a u64 on the wire and dpll_pin_freq_set() keeps it
as one, but dpll_pin_is_freq_supported() takes a u32 while the ranges it
compares against are u64. The supported-frequency check therefore only
looks at the low 32 bits, and the full value is what reaches the driver.

Nothing is hitting this today. Reaching it at all needs a pin-set above
U32_MAX, which no sane caller sends, and the outcome is mild: a pin
advertising 10 kHz accepts 0x1_0000_2710, ice narrows it straight back to
10 kHz in ice_dpll_pin_freq_set(), so the hardware still ends up on an
advertised frequency and only the "frequency is not supported by the
device" rejection goes missing. The other direction - a legitimate request
above U32_MAX wrapping out of the pin's range - needs a driver advertising
such a range, and none does; zl3073x_pin_check_freq() refuses one outright.

So this is types rather than a live bug. Widen the check to match the
attribute, the ranges and the driver callback instead of adding a U32_MAX
rejection, so that the second case stays right if such a driver appears.
dpll_pin_esync_set() already keeps u64 throughout its equivalent loop.

Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Link: https://patch.msgid.link/20260924231211.568213-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
Jakub Kicinski 2026-09-24 16:12:09 -07:00
parent 83cfac9d70
commit 7f92b7f381

View File

@ -608,7 +608,7 @@ dpll_msg_add_pin_ref_sync(struct sk_buff *msg, struct dpll_pin *pin,
return -EMSGSIZE;
}
static bool dpll_pin_is_freq_supported(struct dpll_pin *pin, u32 freq)
static bool dpll_pin_is_freq_supported(struct dpll_pin *pin, u64 freq)
{
int fs;