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: <ZhkxJeQSKMxj0O7b@kekkonen.localdomain>
Date: Fri, 12 Apr 2024 13:03:33 +0000
From: Sakari Ailus <sakari.ailus@...ux.intel.com>
To: Umang Jain <umang.jain@...asonboard.com>
Cc: linux-media@...r.kernel.org,
	Alexander Shiyan <eagle.alexander923@...il.com>,
	Kieran Bingham <kieran.bingham@...asonboard.com>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 2/6] media: imx335: Parse fwnode properties

Hi Umang,

On Fri, Apr 12, 2024 at 05:58:38PM +0530, Umang Jain wrote:
> From: Kieran Bingham <kieran.bingham@...asonboard.com>
> 
> Call the V4L2 fwnode device parser to handle controls that are
> standardised by the framework.
> 
> Signed-off-by: Kieran Bingham <kieran.bingham@...asonboard.com>
> Signed-off-by: Umang Jain <umang.jain@...asonboard.com>
> ---
>  drivers/media/i2c/imx335.c | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/i2c/imx335.c b/drivers/media/i2c/imx335.c
> index c633ea1380e7..3ea9c0ebe278 100644
> --- a/drivers/media/i2c/imx335.c
> +++ b/drivers/media/i2c/imx335.c
> @@ -1227,10 +1227,12 @@ static int imx335_init_controls(struct imx335 *imx335)
>  {
>  	struct v4l2_ctrl_handler *ctrl_hdlr = &imx335->ctrl_handler;
>  	const struct imx335_mode *mode = imx335->cur_mode;
> +	struct v4l2_fwnode_device_properties props;
>  	u32 lpfr;
>  	int ret;
>  
> -	ret = v4l2_ctrl_handler_init(ctrl_hdlr, 7);
> +	/* v4l2_fwnode_device_properties can add two more controls */
> +	ret = v4l2_ctrl_handler_init(ctrl_hdlr, 9);
>  	if (ret)
>  		return ret;
>  
> @@ -1295,9 +1297,15 @@ static int imx335_init_controls(struct imx335 *imx335)
>  	if (imx335->hblank_ctrl)
>  		imx335->hblank_ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>  
> -	if (ctrl_hdlr->error) {
> -		dev_err(imx335->dev, "control init failed: %d\n",
> -			ctrl_hdlr->error);
> +	ret = v4l2_fwnode_device_parse(imx335->dev, &props);
> +	if (!ret) {
> +		/* Failure sets ctrl_hdlr->error, which we check afterwards anyway */
> +		v4l2_ctrl_new_fwnode_properties(ctrl_hdlr, &imx335_ctrl_ops,
> +						&props);
> +	}
> +
> +	if (ctrl_hdlr->error || ret) {
> +		dev_err(imx335->dev, "control init failed: %d\n", ctrl_hdlr->error);

Too long line.

>  		v4l2_ctrl_handler_free(ctrl_hdlr);
>  		return ctrl_hdlr->error;

The handler may not be in error state if only v4l2_fwnode_device_parse()
failed.

Should that be something that should prevent probing a driver though, or
could it just be ignored? I.e. in that case I'd only check for handler's
error, not ret.

>  	}

-- 
Kind regards,

Sakari Ailus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ