[PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Wolfram Sang]

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(-)

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

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Simon Horman]

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
> 

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Daniel Vetter]

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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Daniel Thompson]

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.

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Lee Jones]

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");

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

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Simon Horman]

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.

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Geert Uytterhoeven]

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

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Lee Jones]

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).

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