Re: [PATCH v2 2/2] media: i2c: hm1092: add Himax HM1092 mono NIR sensor driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The driver incorrectly returns `-EPROBE_DEFER` when the static fwnode graph endpoint is missing.
- [Medium] The driver fails to initialize and clamp V4L2 colorimetry fields in `hm1092_update_pad_format()`.
--

commit e540c6418febd9d4f99cda20bb83d2a99d4aaeeb
Author: Ramshouriesh R <rshouriesh@gmail.com>
Subject: media: i2c: hm1092: add Himax HM1092 mono NIR sensor driver

Add a V4L2 subdev driver for the Himax HM1092, a 1 megapixel monochrome
near-infrared image sensor with a single-lane MIPI CSI-2 interface,
typically used as the face-authentication IR camera on laptops.

> diff --git a/drivers/media/i2c/hm1092.c b/drivers/media/i2c/hm1092.c
> new file mode 100644
> index 0000000000000..d0e417c9e35df
> --- /dev/null
> +++ b/drivers/media/i2c/hm1092.c

[ ... ]

> +static void hm1092_update_pad_format(struct v4l2_mbus_framefmt *fmt)
> +{
> +	fmt->width = hm1092_mode_560x360.width;
> +	fmt->height = hm1092_mode_560x360.height;
> +	fmt->code = MEDIA_BUS_FMT_Y10_1X10;
> +	fmt->field = V4L2_FIELD_NONE;
> +}

[Severity: Medium]
Does this code need to initialize and clamp the V4L2 colorimetry fields
(colorspace, ycbcr_enc, quantization, and xfer_func)?

If these fields are not overwritten here, they seem to retain arbitrary
user-supplied values when called from VIDIOC_SUBDEV_S_FMT, instead of
enforcing the correct colorimetry for a monochrome raw sensor
(e.g., V4L2_COLORSPACE_RAW).

[ ... ]

> +static int hm1092_set_format(struct v4l2_subdev *sd,
> +			     struct v4l2_subdev_state *state,
> +			     struct v4l2_subdev_format *fmt)
> +{
> +	hm1092_update_pad_format(&fmt->format);
> +	*v4l2_subdev_state_get_format(state, fmt->pad) = fmt->format;

[Severity: Medium]
Because the colorimetry fields aren't validated or sanitized in
hm1092_update_pad_format(), can this allow arbitrary or invalid values from
user-space to be copied verbatim into the active V4L2 state here?

This might potentially break V4L2 specification compliance and format
negotiation.

> +
> +	return 0;
> +}

[ ... ]

> +static int hm1092_check_hwcfg(struct hm1092 *hm1092)
> +{
> +	struct v4l2_fwnode_endpoint bus_cfg = {
> +		.bus_type = V4L2_MBUS_CSI2_DPHY,
> +	};
> +	struct device *dev = hm1092->dev;
> +	struct fwnode_handle *ep, *fwnode = dev_fwnode(dev);
> +	unsigned long link_freq_bitmap;
> +	int ret;
> +
> +	ep = fwnode_graph_get_endpoint_by_id(fwnode, 0, 0, 0);
> +	if (!ep)
> +		return dev_err_probe(dev, -EPROBE_DEFER,
> +				     "waiting for fwnode graph endpoint\n");

[Severity: Medium]
Should this return a permanent error like -EINVAL or -ENODEV instead of
-EPROBE_DEFER?

The device's fwnode graph endpoint is a static hardware property provided by
the firmware (Device Tree or ACPI). If fwnode_graph_get_endpoint_by_id()
returns NULL, it indicates a permanent misconfiguration rather than a
temporary state where a dependent resource is missing.

Returning -EPROBE_DEFER here could cause the driver core to continually retry
probing in the deferred probe workqueue indefinitely, wasting resources
rather than cleanly failing.

> +
> +	ret = v4l2_fwnode_endpoint_alloc_parse(ep, &bus_cfg);
> +	fwnode_handle_put(ep);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-hm1092-driver-v2-0-4f9f369d6a48@gmail.com?part=2