| Message ID | 20180410123241.25745-1-wsa+renesas@sang-engineering.com |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | [RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction | expand |
On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote: > The documentation was wrong, gpiod_get_direction() returns 0/1 instead > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 > ("gpio: correct docs about return value of gpiod_get_direction"). Now, > fix this user (until a better, system-wide solution is in place). > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> > --- > > Changes since V1: > * rebased to top-of-linus-tree > * added tag from Daniel, thanks! > > Through which tree does this need to go? > > drivers/video/backlight/pwm_bl.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > index 1c2289ddd555..0fa7d2bd0e48 100644 > --- a/drivers/video/backlight/pwm_bl.c > +++ b/drivers/video/backlight/pwm_bl.c > @@ -301,14 +301,14 @@ static int pwm_backlight_probe(struct platform_device *pdev) > > /* > * If the GPIO is not known to be already configured as output, that > - * is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL, > - * change the direction to output and set the GPIO as active. > + * is, if gpiod_get_direction returns either 1 or -EINVAL, change the > + * direction to output and set the GPIO as active. > * Do not force the GPIO to active when it was already output as it > * could cause backlight flickering or we would enable the backlight too > * early. Leave the decision of the initial backlight state for later. > */ > if (pb->enable_gpio && > - gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT) > + gpiod_get_direction(pb->enable_gpio) != 0) > gpiod_direction_output(pb->enable_gpio, 1); > > pb->power_supply = devm_regulator_get(&pdev->dev, "power"); > -- > 2.11.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 11, 2018 at 09:32:16AM +0200, Simon Horman wrote: > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote: > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 > > ("gpio: correct docs about return value of gpiod_get_direction"). Now, > > fix this user (until a better, system-wide solution is in place). > > > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > > Reviewed-by: Simon Horman <horms+renesas@verge.net.au> > > > --- > > > > Changes since V1: > > * rebased to top-of-linus-tree > > * added tag from Daniel, thanks! > > > > Through which tree does this need to go? I think Daniel Thompson has one ... -Daniel > > > > drivers/video/backlight/pwm_bl.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > > index 1c2289ddd555..0fa7d2bd0e48 100644 > > --- a/drivers/video/backlight/pwm_bl.c > > +++ b/drivers/video/backlight/pwm_bl.c > > @@ -301,14 +301,14 @@ static int pwm_backlight_probe(struct platform_device *pdev) > > > > /* > > * If the GPIO is not known to be already configured as output, that > > - * is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL, > > - * change the direction to output and set the GPIO as active. > > + * is, if gpiod_get_direction returns either 1 or -EINVAL, change the > > + * direction to output and set the GPIO as active. > > * Do not force the GPIO to active when it was already output as it > > * could cause backlight flickering or we would enable the backlight too > > * early. Leave the decision of the initial backlight state for later. > > */ > > if (pb->enable_gpio && > > - gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT) > > + gpiod_get_direction(pb->enable_gpio) != 0) > > gpiod_direction_output(pb->enable_gpio, 1); > > > > pb->power_supply = devm_regulator_get(&pdev->dev, "power"); > > -- > > 2.11.0 > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Apr 13, 2018 at 06:08:24PM +0200, Daniel Vetter wrote: > On Wed, Apr 11, 2018 at 09:32:16AM +0200, Simon Horman wrote: > > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote: > > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead > > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 > > > ("gpio: correct docs about return value of gpiod_get_direction"). Now, > > > fix this user (until a better, system-wide solution is in place). > > > > > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > > > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > > > > Reviewed-by: Simon Horman <horms+renesas@verge.net.au> > > > > > --- > > > > > > Changes since V1: > > > * rebased to top-of-linus-tree > > > * added tag from Daniel, thanks! > > > > > > Through which tree does this need to go? > > I think Daniel Thompson has one ... Sorry, I didn't spot the question at the bottom of the change block. For backlight patches generally go though Lee Jones' tree. Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 11 Apr 2018, Simon Horman wrote: > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote: > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 > > ("gpio: correct docs about return value of gpiod_get_direction"). Now, > > fix this user (until a better, system-wide solution is in place). > > > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > > Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Thanks for the Reviewed-by Simon. I have applied it to the original mail. Do you know why you mail wasn't sent attached to the original thread? For some reason I received this mail on it's own i.e. not in reply to the original. > > --- > > > > Changes since V1: > > * rebased to top-of-linus-tree > > * added tag from Daniel, thanks! > > > > Through which tree does this need to go? > > > > drivers/video/backlight/pwm_bl.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > > index 1c2289ddd555..0fa7d2bd0e48 100644 > > --- a/drivers/video/backlight/pwm_bl.c > > +++ b/drivers/video/backlight/pwm_bl.c > > @@ -301,14 +301,14 @@ static int pwm_backlight_probe(struct platform_device *pdev) > > > > /* > > * If the GPIO is not known to be already configured as output, that > > - * is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL, > > - * change the direction to output and set the GPIO as active. > > + * is, if gpiod_get_direction returns either 1 or -EINVAL, change the > > + * direction to output and set the GPIO as active. > > * Do not force the GPIO to active when it was already output as it > > * could cause backlight flickering or we would enable the backlight too > > * early. Leave the decision of the initial backlight state for later. > > */ > > if (pb->enable_gpio && > > - gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT) > > + gpiod_get_direction(pb->enable_gpio) != 0) > > gpiod_direction_output(pb->enable_gpio, 1); > > > > pb->power_supply = devm_regulator_get(&pdev->dev, "power");
On Mon, Apr 16, 2018 at 10:12:57AM +0100, Lee Jones wrote: > On Wed, 11 Apr 2018, Simon Horman wrote: > > > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote: > > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead > > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 > > > ("gpio: correct docs about return value of gpiod_get_direction"). Now, > > > fix this user (until a better, system-wide solution is in place). > > > > > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > > > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > > > > Reviewed-by: Simon Horman <horms+renesas@verge.net.au> > > Thanks for the Reviewed-by Simon. I have applied it to the original mail. > > Do you know why you mail wasn't sent attached to the original thread? > For some reason I received this mail on it's own i.e. not in reply > to the original. No, not off hand. Perhaps I responded to the email in some unusual way but by now I don't recall. In any case I'll try to be more careful in future. -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 24, 2018 at 10:41 AM, Simon Horman <horms@verge.net.au> wrote: > On Mon, Apr 16, 2018 at 10:12:57AM +0100, Lee Jones wrote: >> On Wed, 11 Apr 2018, Simon Horman wrote: >> > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote: >> > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead >> > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 >> > > ("gpio: correct docs about return value of gpiod_get_direction"). Now, >> > > fix this user (until a better, system-wide solution is in place). >> > > >> > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> >> > > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> >> > >> > Reviewed-by: Simon Horman <horms+renesas@verge.net.au> >> >> Thanks for the Reviewed-by Simon. I have applied it to the original mail. >> >> Do you know why you mail wasn't sent attached to the original thread? >> For some reason I received this mail on it's own i.e. not in reply >> to the original. > > No, not off hand. Perhaps I responded to the email in some unusual way > but by now I don't recall. In any case I'll try to be more careful > in future. I see Lee is using gmail for sending, so I assume also for receiving. While I did receive Simon's reply in-thread, lately I had issues with gmail not always doing so, and sometimes failing to do deduplication when receiving email through multiple paths (mailing lists and/or directly). Gr{oetje,eeting}s, Geert
On Tue, 24 Apr 2018, Geert Uytterhoeven wrote: > On Tue, Apr 24, 2018 at 10:41 AM, Simon Horman <horms@verge.net.au> wrote: > > On Mon, Apr 16, 2018 at 10:12:57AM +0100, Lee Jones wrote: > >> On Wed, 11 Apr 2018, Simon Horman wrote: > >> > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote: > >> > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead > >> > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 > >> > > ("gpio: correct docs about return value of gpiod_get_direction"). Now, > >> > > fix this user (until a better, system-wide solution is in place). > >> > > > >> > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > >> > > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > >> > > >> > Reviewed-by: Simon Horman <horms+renesas@verge.net.au> > >> > >> Thanks for the Reviewed-by Simon. I have applied it to the original mail. > >> > >> Do you know why you mail wasn't sent attached to the original thread? > >> For some reason I received this mail on it's own i.e. not in reply > >> to the original. > > > > No, not off hand. Perhaps I responded to the email in some unusual way > > but by now I don't recall. In any case I'll try to be more careful > > in future. > > I see Lee is using gmail for sending, so I assume also for receiving. Well I'm using their servers, but my set-up is IMAP/Mutt. > While I did receive Simon's reply in-thread, lately I had issues with gmail > not always doing so, and sometimes failing to do deduplication when receiving > email through multiple paths (mailing lists and/or directly).
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index 1c2289ddd555..0fa7d2bd0e48 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -301,14 +301,14 @@ static int pwm_backlight_probe(struct platform_device *pdev) /* * If the GPIO is not known to be already configured as output, that - * is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL, - * change the direction to output and set the GPIO as active. + * is, if gpiod_get_direction returns either 1 or -EINVAL, change the + * direction to output and set the GPIO as active. * Do not force the GPIO to active when it was already output as it * could cause backlight flickering or we would enable the backlight too * early. Leave the decision of the initial backlight state for later. */ if (pb->enable_gpio && - gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT) + gpiod_get_direction(pb->enable_gpio) != 0) gpiod_direction_output(pb->enable_gpio, 1); pb->power_supply = devm_regulator_get(&pdev->dev, "power");
The documentation was wrong, gpiod_get_direction() returns 0/1 instead of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 ("gpio: correct docs about return value of gpiod_get_direction"). Now, fix this user (until a better, system-wide solution is in place). Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> --- Changes since V1: * rebased to top-of-linus-tree * added tag from Daniel, thanks! Through which tree does this need to go? drivers/video/backlight/pwm_bl.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)