@@ -2143,6 +2143,7 @@ static int ccs_set_format_source(struct v4l2_subdev *subdev,
*old_csi_format = sensor->csi_format;
unsigned long *valid_link_freqs;
u32 code = fmt->format.code;
+ unsigned int min, max;
unsigned int i;
int rval;
@@ -2179,10 +2180,13 @@ static int ccs_set_format_source(struct v4l2_subdev *subdev,
&sensor->valid_link_freqs[sensor->csi_format->compressed
- sensor->compressed_min_bpp];
- __v4l2_ctrl_modify_range(
- sensor->link_freq, 0,
- __fls(*valid_link_freqs), ~*valid_link_freqs,
- __ffs(*valid_link_freqs));
+ min = __ffs(*valid_link_freqs);
+ man = __fls(*valid_link_freqs);
+
+ ret = __v4l2_ctrl_modify_range(sensor->link_freq, min, max,
+ ~*valid_link_freqs, min);
+ if (ret)
+ return ret;
return ccs_pll_update(sensor);
}
When updating the link frequency control range in response to a format change, the minimum value passed to the __v4l2_ctrl_modify_range() function is hardcoded to 0, while there's no guarantee that the first link frequency in the menu is valid for the selected format. Fix it by getting using the index of the first bit set in the valid link frequencies mask. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> --- I noticed this issue in the CCS driver while working on a different sensor driver. I haven't tested this patch. --- drivers/media/i2c/ccs/ccs-core.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) base-commit: afcd48134c58d6af45fb3fdb648f1260b20f2326