[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aPaOxb9DyQfnU7_Q@valkosipuli.retiisi.eu>
Date: Mon, 20 Oct 2025 22:34:29 +0300
From: Sakari Ailus <sakari.ailus@....fi>
To: Ricardo Ribalda <ribalda@...omium.org>
Cc: Dan Carpenter <dan.carpenter@...aro.org>,
Ricardo Ribalda <ribalda@...nel.org>,
Hans Verkuil <hverkuil+cisco@...nel.org>,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] media: i2c: imx214: Exit early on control init errors
Hi Ricardo,
On Mon, Oct 20, 2025 at 08:51:44PM +0200, Ricardo Ribalda wrote:
> Hi Sakari
>
> On Mon, 20 Oct 2025 at 20:28, Sakari Ailus <sakari.ailus@....fi> wrote:
> >
> > Hi Ricardo,
> >
> > On Tue, Oct 14, 2025 at 11:00:17AM +0000, Ricardo Ribalda wrote:
> > > Now we try to initialize all the controls and at the very end check
> > > ctrl_hdlr->error to check if one of them has failed.
> > >
> > > This confuses smatch, who do not know how to track the state of
> > > imx214->link_freq.
> > >
> > > drivers/media/i2c/imx214.c:1109 imx214_ctrls_init() error: we previously assumed 'imx214->link_freq' could be null (see line 1017)
> > >
> > > Fix this by exiting early on control initialization errors.
> > >
> > > Signed-off-by: Ricardo Ribalda <ribalda@...omium.org>
> > > ---
> > > Right now we are handling this with a quirk in media-ci, if Dan cannot
> > > fix smatch in a kernel cycle we should merge this patch.
> > > ---
> > > Changes in v2:
> > > - Fix typo in commit message commit
> > > - Move error tag where it belongs (Thanks Hans!)
> > > - Link to v1: https://lore.kernel.org/r/20250829-imx214-smatch-v1-1-f3d1653b48e4@chromium.org
> > > ---
> > > drivers/media/i2c/imx214.c | 7 +++++--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
> > > index 94ebe625c9e6ee0fb67fe1d89b48b2f1bf58ffc6..c66f0e18726c3fc15df91c37888a797bcea82134 100644
> > > --- a/drivers/media/i2c/imx214.c
> > > +++ b/drivers/media/i2c/imx214.c
> > > @@ -1014,8 +1014,10 @@ static int imx214_ctrls_init(struct imx214 *imx214)
> > > V4L2_CID_LINK_FREQ,
> > > imx214->bus_cfg.nr_of_link_frequencies - 1,
> > > 0, imx214->bus_cfg.link_frequencies);
> > > - if (imx214->link_freq)
> > > - imx214->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> > > + if (!imx214->link_freq)
> > > + goto err_init_ctrl;
> > > +
> > > + imx214->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> >
> > You could do this cleaner by simply moving the assignment after the handler
> > error check. Some drivers do that already.
> >
> > I wonder why this seems to be a problem for smatch in the imx214 driver as
> > the pattern is widely used across the sensor drivers.
>
> Smatch thinks that there could be case where
>
> imx->link_freq = NULL, and imx214_pll_update returns 0.
>
> That is not solved by moving the assignment `imx214->link_freq->flags
> |=` after if (ret)
Did you test this? The smatch message suggests otherwise (but of course
this could just turn into a different smatch error).
>
> I believe Dan is already flagged about this, but I do not think that
> it will be super simple to fix in his code.
>
> If smatch can handle this case before rc5 I will delete this patch.
There are other options, too, such as storing the link frequency index (the
driver won't even support setting it) or the frequency itself.
--
Regards,
Sakari Ailus
Powered by blists - more mailing lists