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] [day] [month] [year] [list]
Date:   Thu, 24 Jun 2021 17:32:04 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Caleb Connolly <caleb@...nolly.tech>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Sam Ravnborg <sam@...nborg.org>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
        <devicetree@...r.kernel.org>, Hans de Goede <hdegoede@...hat.com>, Andy
        Shevchenko <andy.shevchenko@...il.com>," 
        <~postmarketos/upstreaming@...ts.sr.ht>,
        phone-devel@...r.kernel.org, MSM <linux-arm-msm@...r.kernel.org>,
        "open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] drm: panel: sofef00: remove reset GPIO handling

On Sun, May 2, 2021 at 3:43 AM Caleb Connolly <caleb@...nolly.tech> wrote:

> Resetting the panel on fajita causes it to never come back, we aren't
> quite sure why this is so for now lets remove reset handling as it is
> effectively broken. It is also not needed on enchilada.

Where are the device trees for these platforms?

Are there schematics so we/someone with access to the schematics
can figure it out?

It's not something trivial like forgotten to put GPIO_ACTIVE_LOW
on the gpio phandle?

> -static void sofef00_panel_reset(struct sofef00_panel *ctx)
> -{
> -       gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> -       usleep_range(5000, 6000);
> -       gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> -       usleep_range(2000, 3000);
> -       gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> -       usleep_range(12000, 13000);
> -}

This code looks a bit weird to begin with, I don't see the point
with the first setting the gpiod low, either it was low already or
high already neither matters, driving it asserted will assert it
either way.

No big deal though.

> -       ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);

As Bjorn says: just use *_optional and comment the line out in the
device tree if there is a problem.

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ