linux-kernel - RE: [PATCH v12 5/5] media: i2c: imx334: update pixel and link frequency

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:   Tue, 21 Mar 2023 15:41:50 +0000
From:   <Shravan.Chippa@...rochip.com>
To:     <sakari.ailus@....fi>
CC:     <paul.j.murphy@...el.com>, <daniele.alessandrelli@...el.com>,
        <mchehab@...nel.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <shawnguo@...nel.org>,
        <s.hauer@...gutronix.de>, <kernel@...gutronix.de>,
        <festevam@...il.com>, <linux-imx@....com>,
        <linux-media@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v12 5/5] media: i2c: imx334: update pixel and link
 frequency

Hi Sakari,

> -----Original Message-----
> From: Sakari Ailus <sakari.ailus@....fi>
> Sent: 15 March 2023 12:35 AM
> To: shravan Chippa - I35088 <Shravan.Chippa@...rochip.com>
> Cc: paul.j.murphy@...el.com; daniele.alessandrelli@...el.com;
> mchehab@...nel.org; robh+dt@...nel.org; krzysztof.kozlowski+dt@...aro.org;
> shawnguo@...nel.org; s.hauer@...gutronix.de; kernel@...gutronix.de;
> festevam@...il.com; linux-imx@....com; linux-media@...r.kernel.org; linux-
> kernel@...r.kernel.org; devicetree@...r.kernel.org; linux-arm-
> kernel@...ts.infradead.org
> Subject: Re: [PATCH v12 5/5] media: i2c: imx334: update pixel and link frequency
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> Hi Shravan,
> 
> On Wed, Mar 01, 2023 at 01:04:12PM +0530, shravan kumar wrote:
> > @@ -885,7 +895,13 @@ static int imx334_init_pad_cfg(struct v4l2_subdev
> *sd,
> >       struct v4l2_subdev_format fmt = { 0 };
> >
> >       fmt.which = sd_state ? V4L2_SUBDEV_FORMAT_TRY :
> V4L2_SUBDEV_FORMAT_ACTIVE;
> > -     imx334_fill_pad_format(imx334, &supported_modes[0], &fmt);
> > +     fmt->format.code = imx334->cur_code;
> 
> This does not compile.
> 
> > +     imx334_fill_pad_format(imx334, imx334->cur_mode, &fmt);
> > +
> > +     __v4l2_ctrl_modify_range(imx334->link_freq_ctrl, 0,
> > +                              __fls(imx334->menu_skip_mask),
> > +                              ~(imx334->menu_skip_mask),
> > +                              __ffs(imx334->menu_skip_mask));
> 
> You're not holding imx334->mutex here, as you should. Also accessing
> imx334->cur_code should only be done while that mutex is acquired.
> 
> What's the purpose of calling __v4l2_ctrl_modify_range() here, all these values
> are static once probe() function has been called, aren't they?

v4l2_ctrl_new_int_menu() function limiting only upper and lower frequencies max and min, as of now only two frequencies no problem. If we have more frequencies then we may need to use__v4l2_ctrl_modify_range() with skip mask value.

> 
> I'm dropping this patch for now, taking the first four.

I will try to send it as a separate patch.
> 
> >
> >       return imx334_set_pad_format(sd, sd_state, &fmt);  }
> 
> --
> Kind regards,
> 
> Sakari Ailus