All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Cc: "daniel.thompson@linaro.org" <daniel.thompson@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
	"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"b.zolnierkie@samsung.com" <b.zolnierkie@samsung.com>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"patches@linaro.org" <patches@linaro.org>
Subject: Re: [PATCH] backlight: pwm_bl: Fix uninitialized variable
Date: Wed, 18 Jul 2018 13:08:53 +0000	[thread overview]
Message-ID: <20180718130853.GE4641@dell> (raw)
In-Reply-To: <1531918626.16896.22.camel@toradex.com>

On Wed, 18 Jul 2018, Marcel Ziswiler wrote:

> On Wed, 2018-07-18 at 11:12 +0100, Daniel Thompson wrote:
> > On Wed, Jul 18, 2018 at 10:53:35AM +0100, Lee Jones wrote:
> > > On Wed, 18 Jul 2018, Marcel Ziswiler wrote:
> > > 
> > > > On Wed, 2018-07-18 at 09:09 +0100, Lee Jones wrote:
> > > > > On Mon, 16 Jul 2018, Daniel Thompson wrote:
> > > > > 
> > > > > > Currently, if the DT does not define num-interpolated-steps
> > > > > > then
> > > > > > num_steps is undefined and the interpolation code will deploy
> > > > > > randomly.
> > > > > > Fix this.
> > > > > > 
> > > > > > Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation
> > > > > > between
> > > > > > brightness-levels")
> > > > > > Reported-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > > > > Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
> > > > > > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > > > 
> > > > > This line is confusing.  Did you guys author this patch
> > > > > together?
> > > > 
> > > > Yes, I reported it and we came to a conclusion together.
> > > 
> > > It sounds like you need to have all of the tags (except this one).
> > > :)
> > > 
> > >  Reported-by:  for reporting the issue
> > >  Suggested-by: for suggesting a resolution
> > >  Acked-by:     for reviewing it
> > >  Tested-by:    for testing it
> > > 
> > > Signed-off-by usually means you either wrote a significant amount
> > > of
> > > the diffstat or you were part of the submission path.
> > 
> > He did [I don't object to but wouldn't have used the extra brackets
> > you
> > brought up ;-) ].
> 
> Yes, I take all the blame for the extra brackets. Regardless of having
> a masters in CS or not I still prefer too many then too few of them (;-
> p).
> 
> > > > > My guess is that this line should be dropped and the RB and TB
> > > > > tags
> > > > > should remain?  If it was reviewed too, perhaps an AB too?
> > > > 
> > > > I'm OK either way and do not need any explicit authorship to be
> > > > expressed for me.
> > > 
> > > In this instance I suggest keeping Reported-by and Tested-by.
> > > 
> > > > > > Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > > > > ---
> > > > > >  drivers/video/backlight/pwm_bl.c | 17 ++++++++---------
> > > > > >  1 file changed, 8 insertions(+), 9 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > > > b/drivers/video/backlight/pwm_bl.c
> > > > > > index 9ee4c1b735b2..e3c22b79fbcd 100644
> > > > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > > > @@ -299,15 +299,14 @@ static int
> > > > > > pwm_backlight_parse_dt(struct
> > > > > > device *dev,
> > > > > >  		 * interpolation between each of the values
> > > > > > of
> > > > > > brightness levels
> > > > > >  		 * and creates a new pre-computed table.
> > > > > >  		 */
> > > > > > -		of_property_read_u32(node, "num-
> > > > > > interpolated-
> > > > > > steps",
> > > > > > -				     &num_steps);
> > > > > > -
> > > > > > -		/*
> > > > > > -		 * Make sure that there is at least two
> > > > > > entries in
> > > > > > the
> > > > > > -		 * brightness-levels table, otherwise we
> > > > > > can't
> > > > > > interpolate
> > > > > > -		 * between two points.
> > > > > > -		 */
> > > > > > -		if (num_steps) {
> > > > > > +		if ((of_property_read_u32(node, "num-
> > > > > > interpolated-
> > > > > > steps",
> > > > > > +					  &num_steps) = 0)
> > > > > > &&
> > > > > > num_steps) {
> > > > > 
> > > > > This is pretty ugly, and isn't it suffering from over-
> > > > > bracketing?  My
> > > > > suggestion would be to break out the invocation of
> > > > > of_property_read_u32() from the if and test only the result.
> > > > > 
> > > > > 		of_property_read_u32(node, "num-interpolated-
> > > > > steps", 
> > > > > &num_steps);
> > > > 
> > > > you mean:
> > > > 
> > > > 		ret = of_property_read_u32(node, "num-interpolated-
> > > > steps", &num_steps);
> > > > 
> > > > > 		if (!ret && num_steps) {
> > > > > 
> > > > > I haven't checked the underling code, but is it even feasible
> > > > > for
> > > > > of_property_read_u32() to not succeed AND for num_steps to be
> > > > > set?
> > > > > 
> > > > > If not, the check for !ret if superfluous and you can drop it.
> > > > 
> > > > No, then we are back to the initial issue of num_steps
> > > > potentially not
> > > > being initialised. We really want both of_property_read_u32() to
> > > > succeed AND num_steps to actually be set.
> > > 
> > > I also think num_steps should be pre-initialised.
> 
> Yes, I guess it definitely does not hurt.
> 
> > > Then it will only be set if of_property_read_u32() succeeds.
> 
> Yes, but we still need to check for both, the function not failing and
> num_steps to actually be non zero.

Why?  You don't do anything differently if it fails.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Cc: "daniel.thompson@linaro.org" <daniel.thompson@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
	"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"b.zolnierkie@samsung.com" <b.zolnierkie@samsung.com>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"patches@linaro.org" <patches@linaro.org>
Subject: Re: [PATCH] backlight: pwm_bl: Fix uninitialized variable
Date: Wed, 18 Jul 2018 14:08:53 +0100	[thread overview]
Message-ID: <20180718130853.GE4641@dell> (raw)
In-Reply-To: <1531918626.16896.22.camel@toradex.com>

On Wed, 18 Jul 2018, Marcel Ziswiler wrote:

> On Wed, 2018-07-18 at 11:12 +0100, Daniel Thompson wrote:
> > On Wed, Jul 18, 2018 at 10:53:35AM +0100, Lee Jones wrote:
> > > On Wed, 18 Jul 2018, Marcel Ziswiler wrote:
> > > 
> > > > On Wed, 2018-07-18 at 09:09 +0100, Lee Jones wrote:
> > > > > On Mon, 16 Jul 2018, Daniel Thompson wrote:
> > > > > 
> > > > > > Currently, if the DT does not define num-interpolated-steps
> > > > > > then
> > > > > > num_steps is undefined and the interpolation code will deploy
> > > > > > randomly.
> > > > > > Fix this.
> > > > > > 
> > > > > > Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation
> > > > > > between
> > > > > > brightness-levels")
> > > > > > Reported-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > > > > Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
> > > > > > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > > > 
> > > > > This line is confusing.  Did you guys author this patch
> > > > > together?
> > > > 
> > > > Yes, I reported it and we came to a conclusion together.
> > > 
> > > It sounds like you need to have all of the tags (except this one).
> > > :)
> > > 
> > >  Reported-by:  for reporting the issue
> > >  Suggested-by: for suggesting a resolution
> > >  Acked-by:     for reviewing it
> > >  Tested-by:    for testing it
> > > 
> > > Signed-off-by usually means you either wrote a significant amount
> > > of
> > > the diffstat or you were part of the submission path.
> > 
> > He did [I don't object to but wouldn't have used the extra brackets
> > you
> > brought up ;-) ].
> 
> Yes, I take all the blame for the extra brackets. Regardless of having
> a masters in CS or not I still prefer too many then too few of them (;-
> p).
> 
> > > > > My guess is that this line should be dropped and the RB and TB
> > > > > tags
> > > > > should remain?  If it was reviewed too, perhaps an AB too?
> > > > 
> > > > I'm OK either way and do not need any explicit authorship to be
> > > > expressed for me.
> > > 
> > > In this instance I suggest keeping Reported-by and Tested-by.
> > > 
> > > > > > Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > > > > ---
> > > > > >  drivers/video/backlight/pwm_bl.c | 17 ++++++++---------
> > > > > >  1 file changed, 8 insertions(+), 9 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > > > b/drivers/video/backlight/pwm_bl.c
> > > > > > index 9ee4c1b735b2..e3c22b79fbcd 100644
> > > > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > > > @@ -299,15 +299,14 @@ static int
> > > > > > pwm_backlight_parse_dt(struct
> > > > > > device *dev,
> > > > > >  		 * interpolation between each of the values
> > > > > > of
> > > > > > brightness levels
> > > > > >  		 * and creates a new pre-computed table.
> > > > > >  		 */
> > > > > > -		of_property_read_u32(node, "num-
> > > > > > interpolated-
> > > > > > steps",
> > > > > > -				     &num_steps);
> > > > > > -
> > > > > > -		/*
> > > > > > -		 * Make sure that there is at least two
> > > > > > entries in
> > > > > > the
> > > > > > -		 * brightness-levels table, otherwise we
> > > > > > can't
> > > > > > interpolate
> > > > > > -		 * between two points.
> > > > > > -		 */
> > > > > > -		if (num_steps) {
> > > > > > +		if ((of_property_read_u32(node, "num-
> > > > > > interpolated-
> > > > > > steps",
> > > > > > +					  &num_steps) == 0)
> > > > > > &&
> > > > > > num_steps) {
> > > > > 
> > > > > This is pretty ugly, and isn't it suffering from over-
> > > > > bracketing?  My
> > > > > suggestion would be to break out the invocation of
> > > > > of_property_read_u32() from the if and test only the result.
> > > > > 
> > > > > 		of_property_read_u32(node, "num-interpolated-
> > > > > steps", 
> > > > > &num_steps);
> > > > 
> > > > you mean:
> > > > 
> > > > 		ret = of_property_read_u32(node, "num-interpolated-
> > > > steps", &num_steps);
> > > > 
> > > > > 		if (!ret && num_steps) {
> > > > > 
> > > > > I haven't checked the underling code, but is it even feasible
> > > > > for
> > > > > of_property_read_u32() to not succeed AND for num_steps to be
> > > > > set?
> > > > > 
> > > > > If not, the check for !ret if superfluous and you can drop it.
> > > > 
> > > > No, then we are back to the initial issue of num_steps
> > > > potentially not
> > > > being initialised. We really want both of_property_read_u32() to
> > > > succeed AND num_steps to actually be set.
> > > 
> > > I also think num_steps should be pre-initialised.
> 
> Yes, I guess it definitely does not hurt.
> 
> > > Then it will only be set if of_property_read_u32() succeeds.
> 
> Yes, but we still need to check for both, the function not failing and
> num_steps to actually be non zero.

Why?  You don't do anything differently if it fails.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2018-07-18 13:08 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-16 21:02 [PATCH] backlight: pwm_bl: Fix uninitialized variable Daniel Thompson
2018-07-16 21:02 ` Daniel Thompson
2018-07-18  8:09 ` Lee Jones
2018-07-18  8:09   ` Lee Jones
2018-07-18  8:12   ` Lee Jones
2018-07-18  8:12     ` Lee Jones
2018-07-18  8:12     ` Lee Jones
2018-07-18  8:22   ` Marcel Ziswiler
2018-07-18  8:22     ` Marcel Ziswiler
2018-07-18  9:53     ` Lee Jones
2018-07-18  9:53       ` Lee Jones
2018-07-18  9:53       ` Lee Jones
2018-07-18 10:12       ` Daniel Thompson
2018-07-18 10:12         ` Daniel Thompson
2018-07-18 12:57         ` Marcel Ziswiler
2018-07-18 12:57           ` Marcel Ziswiler
2018-07-18 13:08           ` Lee Jones [this message]
2018-07-18 13:08             ` Lee Jones
2018-07-18 13:26             ` Marcel Ziswiler
2018-07-18 13:26               ` Marcel Ziswiler
2018-07-18 13:41             ` Daniel Thompson
2018-07-18 13:41               ` Daniel Thompson
2018-07-18 13:41               ` Daniel Thompson
2018-07-18 15:55               ` Lee Jones
2018-07-18 15:55                 ` Lee Jones
2018-07-18 15:55                 ` Lee Jones
2018-07-18 16:34                 ` Daniel Thompson
2018-07-18 16:34                   ` Daniel Thompson
2018-07-18 16:34                   ` Daniel Thompson
2018-07-23  7:25                   ` Lee Jones
2018-07-23  7:25                     ` Lee Jones
2018-07-23  7:25                     ` Lee Jones
2018-07-18  8:26   ` Daniel Thompson
2018-07-18  8:26     ` Daniel Thompson
2018-07-18  8:26     ` Daniel Thompson
2018-07-19 16:19 ` [PATCH v2] " Daniel Thompson
2018-07-19 16:19   ` Daniel Thompson
2018-07-19 16:19   ` Daniel Thompson
2018-07-23  7:23   ` Lee Jones
2018-07-23  7:23     ` Lee Jones
2018-07-24  6:48     ` Daniel Thompson
2018-07-24  6:48       ` Daniel Thompson
2018-07-24  7:01     ` Daniel Thompson
2018-07-24  7:01       ` Daniel Thompson
2018-07-24  7:01       ` Daniel Thompson
2018-07-24  7:12 ` [PATCH v3] " Daniel Thompson
2018-07-24  7:12   ` Daniel Thompson
2018-07-24  7:12   ` Daniel Thompson
2018-07-24 23:56   ` Doug Anderson
2018-07-24 23:56     ` Doug Anderson
2018-07-25  5:22   ` Lee Jones
2018-07-25  5:22     ` Lee Jones
2018-07-25  5:22     ` Lee Jones
2018-07-25  7:38 ` [PATCH v4] " Daniel Thompson
2018-07-25  7:38   ` Daniel Thompson
2018-07-25  7:38   ` Daniel Thompson
2018-07-25  8:03   ` Lee Jones
2018-07-25  8:03     ` Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180718130853.GE4641@dell \
    --to=lee.jones@linaro.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=daniel.thompson@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jingoohan1@gmail.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=marcel.ziswiler@toradex.com \
    --cc=patches@linaro.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.