Re: [PATCH v5 02/16] media: iris: Filter UBWC raw formats based on hardware capabilities

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `iris_vdec_formats_noubwc_cap` array contains a zero-initialized gap at index 1, which prematurely terminates V4L2 format enumeration and improperly validates 0 as a valid pixel format.
--

commit 1ff6b6e464175bc1ccf6878e0aa89ffec126608b
Author: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>

media: iris: Filter UBWC raw formats based on hardware capabilities

The raw formats supported by Iris were previously advertised
unconditionally, assuming UBWC support on all platforms. Use the UBWC
configuration provided by the platform to dynamically filter raw formats
at runtime, keeping linear formats available when UBWC is not supported.

> diff --git a/drivers/media/platform/qcom/iris/iris_vdec.c b/drivers/media/platform/qcom/iris/iris_vdec.c
> index 9e228b70420e4..63b7c9dec60a0 100644
> --- a/drivers/media/platform/qcom/iris/iris_vdec.c
> +++ b/drivers/media/platform/qcom/iris/iris_vdec.c
[ ... ]
> @@ -69,8 +70,14 @@ static const u32 iris_vdec_formats_cap[] = {
>  	[IRIS_FMT_QC10C] =  V4L2_PIX_FMT_QC10C,
>  };
>  
> +static const u32 iris_vdec_formats_noubwc_cap[] = {
> +	[IRIS_FMT_NV12] = V4L2_PIX_FMT_NV12,
> +	[IRIS_FMT_TP10] =  V4L2_PIX_FMT_P010,
> +};

[Severity: High]
Does this create a sparse array with a zero-initialized gap at index 1?

Because IRIS_FMT_NV12 is 0 and IRIS_FMT_TP10 is 2, skipping index 1 
(IRIS_FMT_QC08C) implicitly initializes it to 0.

When check_format() in iris_vdec.c iterates through this array:

	for (i = 0; i < size; i++) {
		if (fmt[i] == pixfmt)
			break;
	}

Won't it incorrectly accept 0 as a valid pixel format by matching against the
uninitialized gap?

[ ... ]
> @@ -110,6 +122,7 @@ static bool check_format(struct iris_inst *inst, u32 pixfmt, u32 type)
>  
>  static u32 find_format_by_index(struct iris_inst *inst, u32 index, u32 type)
>  {
> +	const struct qcom_ubwc_cfg_data *ubwc = inst->core->ubwc_cfg;
>  	unsigned int size;
>  	const u32 *fmt;
>  
> @@ -119,8 +132,13 @@ static u32 find_format_by_index(struct iris_inst *inst, u32 index, u32 type)
>  		size = inst->core->iris_platform_data->inst_iris_fmts_size;
>  		break;
>  	case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> -		fmt = iris_vdec_formats_cap;
> -		size = ARRAY_SIZE(iris_vdec_formats_cap);
> +		if (ubwc->ubwc_enc_version) {
> +			fmt = iris_vdec_formats_cap;
> +			size = ARRAY_SIZE(iris_vdec_formats_cap);
> +		} else {
> +			fmt = iris_vdec_formats_noubwc_cap;
> +			size = ARRAY_SIZE(iris_vdec_formats_noubwc_cap);
> +		}
>  		break;
>  	default:
>  		return 0;

[Severity: High]
Will the V4L2 enumeration stop prematurely when encountering the gap?

Since the V4L2 framework queries formats using a sequential index, querying
index 1 will hit the zero-initialized hole, causing find_format_by_index()
in iris_vdec.c to return 0.

When 0 is returned, V4L2 typically stops enumeration, meaning the valid 10-bit
linear format (V4L2_PIX_FMT_P010) at index 2 will be completely hidden.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-iris-ar50lt-v5-0-583b42770b6a@oss.qualcomm.com?part=2