mirror of
https://github.com/torvalds/linux.git
synced 2026-11-07 06:17:02 +01:00
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:
parent
83cfac9d70
commit
7f92b7f381
|
|
@ -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;
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user