lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 20 Jul 2023 12:27:42 +0100
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Ying Liu <victor.liu@....com>
Cc:     "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "lee@...nel.org" <lee@...nel.org>,
        "jingoohan1@...il.com" <jingoohan1@...il.com>,
        "deller@....de" <deller@....de>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Andy Shevchenko <andy@...nel.org>
Subject: Re: [PATCH] backlight: gpio_backlight: Drop output gpio direction
 check for initial power state

On Thu, Jul 20, 2023 at 06:06:27AM +0000, Ying Liu wrote:
> Bootloader may leave gpio direction as input and gpio value as logical low.
> It hints that initial backlight power state should be FB_BLANK_POWERDOWN
> since the gpio value is literally logical low.

To be honest this probably "hints" that the bootloader simply didn't
consider the backlight at all :-) . I'd rather the patch description
focus on what circumstances lead to the current code making a bad
decision. More like:

  If the GPIO pin is in the input state but the backlight is currently
  off due to default pull downs then ...

> So, let's drop output gpio
> direction check and only check gpio value to set the initial power state.

This check was specifically added by Bartosz so I'd be interested in his
opinion of this change (especially since he is now a GPIO maintainer)!

What motivates (or motivated) the need to check the direction rather
than just read that current logic level on the pin?


Daniel.
[I'm done but since Bartosz and Linus were not on copy of the original
thread I've left the rest of the patch below as a convenience ;-) ]


> Signed-off-by: Liu Ying <victor.liu@....com>
> ---
>  drivers/video/backlight/gpio_backlight.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c b/drivers/video/backlight/gpio_backlight.c
> index d3bea42407f1..d28c30b2a35d 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -87,8 +87,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
>  		/* Not booted with device tree or no phandle link to the node */
>  		bl->props.power = def_value ? FB_BLANK_UNBLANK
>  					    : FB_BLANK_POWERDOWN;
> -	else if (gpiod_get_direction(gbl->gpiod) == 0 &&
> -		 gpiod_get_value_cansleep(gbl->gpiod) == 0)
> +	else if (gpiod_get_value_cansleep(gbl->gpiod) == 0)
>  		bl->props.power = FB_BLANK_POWERDOWN;
>  	else
>  		bl->props.power = FB_BLANK_UNBLANK;
> --
> 2.37.1
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ