linux-kernel - Re: [PATCH v5 2/6] media: imx335: Parse fwnode properties

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] [day] [month] [year] [list]

Date: Fri, 12 Apr 2024 18:46:39 +0530
From: Umang Jain <umang.jain@...asonboard.com>
To: Sakari Ailus <sakari.ailus@...ux.intel.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 Sakari,

On 12/04/24 6:33 pm, Sakari Ailus wrote:
> 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.

I read some more drivers and it seems v4l2_fwnode_device_parse() can 
probably be checked at start of init_controls() and return early on 
non-zero return value.

Is that something that should be done here as well ?
>
> 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.

So we should probably check for ret and ctrl_hdlr->error separately ?
>
>>   	}