[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230804090002.GA12951@pendragon.ideasonboard.com>
Date: Fri, 4 Aug 2023 12:00:02 +0300
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Hans Verkuil <hverkuil@...all.nl>, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] media: i2c: ds90ub9x3: Fix use of uninitialized
variables
On Fri, Aug 04, 2023 at 08:49:28AM +0300, Tomi Valkeinen wrote:
> On 04/08/2023 00:46, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thank you for the patch.
> >
> > On Thu, Aug 03, 2023 at 11:41:38AM +0300, Tomi Valkeinen wrote:
> >> smatch reports some uninitialized variables:
> >>
> >> drivers/media/i2c/ds90ub913.c:481 ub913_log_status() error: uninitialized symbol 'v1'.
> >> drivers/media/i2c/ds90ub913.c:481 ub913_log_status() error: uninitialized symbol 'v2'.
> >> drivers/media/i2c/ds90ub953.c:655 ub953_log_status() error: uninitialized symbol 'gpio_local_data'.
> >> drivers/media/i2c/ds90ub953.c:655 ub953_log_status() error: uninitialized symbol 'gpio_input_ctrl'.
> >> drivers/media/i2c/ds90ub953.c:655 ub953_log_status() error: uninitialized symbol 'gpio_pin_sts'.
> >>
> >> These are used only for printing debug information, and the use of an
> >> uninitialized variable only happens if an i2c transaction has failed,
> >> which will print an error. Thus, fix the errors just by initializing the
> >> variables to 0.
> >>
> >> Fixes: 6363db1c9d45 ("media: i2c: add DS90UB953 driver")
> >> Fixes: c158d0d4ff15 ("media: i2c: add DS90UB913 driver")
> >> Reported-by: Hans Verkuil <hverkuil@...all.nl>
> >> Closes: https://lore.kernel.org/all/8d6daeb1-b62a-bbb2-b840-8759c84f2085@xs4all.nl/
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
> >> ---
> >> drivers/media/i2c/ds90ub913.c | 2 +-
> >> drivers/media/i2c/ds90ub953.c | 6 +++---
> >> 2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/ds90ub913.c b/drivers/media/i2c/ds90ub913.c
> >> index 80d9cf6dd945..b2115e3519e2 100644
> >> --- a/drivers/media/i2c/ds90ub913.c
> >> +++ b/drivers/media/i2c/ds90ub913.c
> >> @@ -469,7 +469,7 @@ static int ub913_log_status(struct v4l2_subdev *sd)
> >> {
> >> struct ub913_data *priv = sd_to_ub913(sd);
> >> struct device *dev = &priv->client->dev;
> >> - u8 v = 0, v1, v2;
> >> + u8 v = 0, v1 = 0, v2 = 0;
> >
> > This seems to work around the lack of error checking when calling
>
> Yes.
>
> > ub913_read(). Wouldn't it be better to check for errors there ? Or,
> > because this is ub913_log_status(), do you consider that we can print an
> > invalid CRC errors count, given that the ub913_read() function will have
> > printed an error message before ?
>
> Yes, that was my thinking. Adding proper error handling would complicate
> the function (more visibly so in ub953 and ub960, which have more
> printing done), and what would be the benefit? Not much, in my opinion.
> If the i2c transactions start to fail, we're in a bad situation anyway
> (and, as you mention, ub913_read() will print errors).
>
> However, I guess the "benefit" depends on the use a bit. If log status
> is used as a debug aid, I think my reasoning is fine. But if it's used
> by some automated script, to collect data, it may be more difficult for
> the script to detect that an error has happened in the log status.
I see log status as a debugging aid only, so I'm fine with your
reasoning.
> That said, I have to say this ignore-errors code somewhat bugs me, so
> maybe I'll improve the log-status functions later. But I think these are
> acceptable fixes to get rid of the smatch errors.
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists