lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <024c232f-bd43-42a9-25e7-0fbe71edbcb0@xs4all.nl>
Date:   Wed, 21 Feb 2018 13:03:24 +0100
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Jacopo Mondi <jacopo+renesas@...ndi.org>,
        laurent.pinchart@...asonboard.com, magnus.damm@...il.com,
        geert@...der.be, mchehab@...nel.org, festevam@...il.com,
        sakari.ailus@....fi, robh+dt@...nel.org, mark.rutland@....com,
        pombredanne@...b.com
Cc:     linux-renesas-soc@...r.kernel.org, linux-media@...r.kernel.org,
        linux-sh@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 03/11] media: platform: Add Renesas CEU driver

On 02/19/18 17:59, Jacopo Mondi wrote:
> Add driver for Renesas Capture Engine Unit (CEU).
> 
> The CEU interface supports capturing 'data' (YUV422) and 'images'
> (NV[12|21|16|61]).
> 
> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
> 
> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> platform GR-Peach.
> 
> Tested with ov7725 camera sensor on SH4 platform Migo-R.
> 
> Signed-off-by: Jacopo Mondi <jacopo+renesas@...ndi.org>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> ---
>  drivers/media/platform/Kconfig       |    9 +
>  drivers/media/platform/Makefile      |    1 +
>  drivers/media/platform/renesas-ceu.c | 1661 ++++++++++++++++++++++++++++++++++
>  3 files changed, 1671 insertions(+)
>  create mode 100644 drivers/media/platform/renesas-ceu.c
> 

<snip>

> +static int ceu_s_input(struct file *file, void *priv, unsigned int i)
> +{
> +	struct ceu_device *ceudev = video_drvdata(file);
> +	struct ceu_subdev *ceu_sd_old;
> +	int ret;
> +
> +	if (i >= ceudev->num_sd)
> +		return -EINVAL;
> +
> +	if (vb2_is_streaming(&ceudev->vb2_vq))
> +		return -EBUSY;
> +
> +	if (i == ceudev->sd_index)
> +		return 0;
> +
> +	ceu_sd_old = ceudev->sd;
> +	ceudev->sd = &ceudev->subdevs[i];
> +
> +	/* Make sure we can generate output image formats. */
> +	ret = ceu_init_formats(ceudev);

Why is this done for every s_input? I would expect that this is done only once
for each subdev.

I also expect to see a ceu_set_default_fmt() call here. Or that the v4l2_pix is kept
in ceu_subdev (i.e. per subdev) instead of a single fmt in cuedev. I think I prefer
that over configuring a new default format every time you switch inputs.

This code will work for two subdevs with exactly the same formats/properties. But
switching between e.g. a sensor and a video receiver will leave things in an
inconsistent state as far as I can see.

E.g. if input 1 is the video receiver then switching to that input and running
'v4l2-ctl -V' will show the sensor format, not the video receiver format.

> +	if (ret) {
> +		ceudev->sd = ceu_sd_old;
> +		return -EINVAL;
> +	}
> +
> +	/* now that we're sure we can use the sensor, power off the old one. */
> +	v4l2_subdev_call(ceu_sd_old->v4l2_sd, core, s_power, 0);
> +	v4l2_subdev_call(ceudev->sd->v4l2_sd, core, s_power, 1);
> +
> +	ceudev->sd_index = i;
> +
> +	return 0;
> +}

The remainder of this driver looks good.

Regards,

	Hans

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ