From 7f92b7f381ffa83800bba6d535ac36a764f3abeb Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Thu, 24 Sep 2026 16:12:09 -0700 Subject: [PATCH] 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 Link: https://patch.msgid.link/20260924231211.568213-2-kuba@kernel.org Signed-off-by: Jakub Kicinski --- drivers/dpll/dpll_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c index fb24fd53f2e1..e5380d95f238 100644 --- a/drivers/dpll/dpll_netlink.c +++ b/drivers/dpll/dpll_netlink.c @@ -608,7 +608,7 @@ nest_cancel: 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;