From: Daniel Thompson <daniel.thompson@linaro.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: linux-pwm@vger.kernel.org, linux-fbdev@vger.kernel.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Marcel Ziswiler <marcel.ziswiler@toradex.com>,
Jingoo Han <jingoohan1@gmail.com>,
patches@linaro.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Thierry Reding <thierry.reding@gmail.com>
Subject: Re: [PATCH v2] backlight: pwm_bl: Fix uninitialized variable
Date: Tue, 24 Jul 2018 07:01:13 +0000 [thread overview]
Message-ID: <20180724070113.GA9871@wychelm.lan> (raw)
In-Reply-To: <20180723072343.GD4213@dell>
On Mon, Jul 23, 2018 at 08:23:43AM +0100, Lee Jones wrote:
> On Thu, 19 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.
> >
> > Additionally fix a small grammar error that was identified and
> > tighten up return code checking of DT properties, both of which came
> > up during review of this patch.
> >
> > 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>
> > Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > ---
> >
> > Notes:
> > v2:
> > - Simplify SoB chain (with Marcel's permission)
> > - Separate complex if statement and make other similar calls use same
> > return code checking approach
> > - Tidy up comment formatting and fix pre-existing grammar error
> >
> > drivers/video/backlight/pwm_bl.c | 25 ++++++++++++-------------
> > 1 file changed, 12 insertions(+), 13 deletions(-)
>
> I'm hesitant to provide feedback on this, as I feel as though I've
> messed you around enough, however ... ;)
>
> > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > index 9ee4c1b735b2..f7799f62fea0 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -284,30 +284,29 @@ static int pwm_backlight_parse_dt(struct device *dev,
> > ret = of_property_read_u32_array(node, "brightness-levels",
> > data->levels,
> > data->max_brightness);
> > - if (ret < 0)
> > + if (!ret)
> > return ret;
> >
> > ret = of_property_read_u32(node, "default-brightness-level",
> > &value);
> > - if (ret < 0)
> > + if (!ret)
> > return ret;
>
> Just FYI (it didn't even make it to 'nit' status), this should really
> be done in a separate patch since it is unrelated to the rest of the
> patch.
Did wonder which way to go on this... I figured this close I'd accept
code either way so adopted fewest patches.
However I will split this out because I'm going to go back to the orignal
pre-v1 approach of just initializing the damn variable.
> > data->dft_brightness = value;
> >
> > /*
> > * This property is optional, if is set enables linear
> > - * interpolation between each of the values of brightness levels
> > - * and creates a new pre-computed table.
> > + * 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) {
> > + ret = of_property_read_u32(node, "num-interpolated-steps",
> > + &num_steps);
> > + if (!ret || num_steps) {
>
> Not sure if it's even possible for of_property_read_u32() to fail AND
> still populate num_steps, however this check makes it sound like that's
> okay. Is that correct?
>
> I can't help but think that this all 'just goes away' if you
> pre-initialise num_steps. I wouldn't let the "do not initialise too
> far away from the code using variable" affect this. However, if
> you're insistent, perhaps consider moving the declaration to just
> below:
>
> if (data->max_brightness > 0) {
>
> > + /*
> > + * Make sure that there are at least two entries in
> > + * the brightness-levels table, otherwise we can't
> > + * interpolate between two points.
> > + */
> > if (data->max_brightness < 2) {
> > dev_err(dev, "can't interpolate\n");
> > return -EINVAL;
>
> --
> 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: Daniel Thompson <daniel.thompson@linaro.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: linux-pwm@vger.kernel.org, linux-fbdev@vger.kernel.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Marcel Ziswiler <marcel.ziswiler@toradex.com>,
Jingoo Han <jingoohan1@gmail.com>,
patches@linaro.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Thierry Reding <thierry.reding@gmail.com>
Subject: Re: [PATCH v2] backlight: pwm_bl: Fix uninitialized variable
Date: Tue, 24 Jul 2018 08:01:13 +0100 [thread overview]
Message-ID: <20180724070113.GA9871@wychelm.lan> (raw)
In-Reply-To: <20180723072343.GD4213@dell>
On Mon, Jul 23, 2018 at 08:23:43AM +0100, Lee Jones wrote:
> On Thu, 19 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.
> >
> > Additionally fix a small grammar error that was identified and
> > tighten up return code checking of DT properties, both of which came
> > up during review of this patch.
> >
> > 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>
> > Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > ---
> >
> > Notes:
> > v2:
> > - Simplify SoB chain (with Marcel's permission)
> > - Separate complex if statement and make other similar calls use same
> > return code checking approach
> > - Tidy up comment formatting and fix pre-existing grammar error
> >
> > drivers/video/backlight/pwm_bl.c | 25 ++++++++++++-------------
> > 1 file changed, 12 insertions(+), 13 deletions(-)
>
> I'm hesitant to provide feedback on this, as I feel as though I've
> messed you around enough, however ... ;)
>
> > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > index 9ee4c1b735b2..f7799f62fea0 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -284,30 +284,29 @@ static int pwm_backlight_parse_dt(struct device *dev,
> > ret = of_property_read_u32_array(node, "brightness-levels",
> > data->levels,
> > data->max_brightness);
> > - if (ret < 0)
> > + if (!ret)
> > return ret;
> >
> > ret = of_property_read_u32(node, "default-brightness-level",
> > &value);
> > - if (ret < 0)
> > + if (!ret)
> > return ret;
>
> Just FYI (it didn't even make it to 'nit' status), this should really
> be done in a separate patch since it is unrelated to the rest of the
> patch.
Did wonder which way to go on this... I figured this close I'd accept
code either way so adopted fewest patches.
However I will split this out because I'm going to go back to the orignal
pre-v1 approach of just initializing the damn variable.
> > data->dft_brightness = value;
> >
> > /*
> > * This property is optional, if is set enables linear
> > - * interpolation between each of the values of brightness levels
> > - * and creates a new pre-computed table.
> > + * 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) {
> > + ret = of_property_read_u32(node, "num-interpolated-steps",
> > + &num_steps);
> > + if (!ret || num_steps) {
>
> Not sure if it's even possible for of_property_read_u32() to fail AND
> still populate num_steps, however this check makes it sound like that's
> okay. Is that correct?
>
> I can't help but think that this all 'just goes away' if you
> pre-initialise num_steps. I wouldn't let the "do not initialise too
> far away from the code using variable" affect this. However, if
> you're insistent, perhaps consider moving the declaration to just
> below:
>
> if (data->max_brightness > 0) {
>
> > + /*
> > + * Make sure that there are at least two entries in
> > + * the brightness-levels table, otherwise we can't
> > + * interpolate between two points.
> > + */
> > if (data->max_brightness < 2) {
> > dev_err(dev, "can't interpolate\n");
> > return -EINVAL;
>
> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Thompson <daniel.thompson@linaro.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: Jingoo Han <jingoohan1@gmail.com>,
Thierry Reding <thierry.reding@gmail.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Marcel Ziswiler <marcel.ziswiler@toradex.com>,
linux-pwm@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
patches@linaro.org
Subject: Re: [PATCH v2] backlight: pwm_bl: Fix uninitialized variable
Date: Tue, 24 Jul 2018 08:01:13 +0100 [thread overview]
Message-ID: <20180724070113.GA9871@wychelm.lan> (raw)
In-Reply-To: <20180723072343.GD4213@dell>
On Mon, Jul 23, 2018 at 08:23:43AM +0100, Lee Jones wrote:
> On Thu, 19 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.
> >
> > Additionally fix a small grammar error that was identified and
> > tighten up return code checking of DT properties, both of which came
> > up during review of this patch.
> >
> > 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>
> > Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > ---
> >
> > Notes:
> > v2:
> > - Simplify SoB chain (with Marcel's permission)
> > - Separate complex if statement and make other similar calls use same
> > return code checking approach
> > - Tidy up comment formatting and fix pre-existing grammar error
> >
> > drivers/video/backlight/pwm_bl.c | 25 ++++++++++++-------------
> > 1 file changed, 12 insertions(+), 13 deletions(-)
>
> I'm hesitant to provide feedback on this, as I feel as though I've
> messed you around enough, however ... ;)
>
> > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > index 9ee4c1b735b2..f7799f62fea0 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -284,30 +284,29 @@ static int pwm_backlight_parse_dt(struct device *dev,
> > ret = of_property_read_u32_array(node, "brightness-levels",
> > data->levels,
> > data->max_brightness);
> > - if (ret < 0)
> > + if (!ret)
> > return ret;
> >
> > ret = of_property_read_u32(node, "default-brightness-level",
> > &value);
> > - if (ret < 0)
> > + if (!ret)
> > return ret;
>
> Just FYI (it didn't even make it to 'nit' status), this should really
> be done in a separate patch since it is unrelated to the rest of the
> patch.
Did wonder which way to go on this... I figured this close I'd accept
code either way so adopted fewest patches.
However I will split this out because I'm going to go back to the orignal
pre-v1 approach of just initializing the damn variable.
> > data->dft_brightness = value;
> >
> > /*
> > * This property is optional, if is set enables linear
> > - * interpolation between each of the values of brightness levels
> > - * and creates a new pre-computed table.
> > + * 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) {
> > + ret = of_property_read_u32(node, "num-interpolated-steps",
> > + &num_steps);
> > + if (!ret || num_steps) {
>
> Not sure if it's even possible for of_property_read_u32() to fail AND
> still populate num_steps, however this check makes it sound like that's
> okay. Is that correct?
>
> I can't help but think that this all 'just goes away' if you
> pre-initialise num_steps. I wouldn't let the "do not initialise too
> far away from the code using variable" affect this. However, if
> you're insistent, perhaps consider moving the declaration to just
> below:
>
> if (data->max_brightness > 0) {
>
> > + /*
> > + * Make sure that there are at least two entries in
> > + * the brightness-levels table, otherwise we can't
> > + * interpolate between two points.
> > + */
> > if (data->max_brightness < 2) {
> > dev_err(dev, "can't interpolate\n");
> > return -EINVAL;
>
> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2018-07-24 7:01 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
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 [this message]
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=20180724070113.GA9871@wychelm.lan \
--to=daniel.thompson@linaro.org \
--cc=b.zolnierkie@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jingoohan1@gmail.com \
--cc=lee.jones@linaro.org \
--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.