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, 6 Jul 2023 14:11:58 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Ruihai Zhou <zhouruihai@...qin.corp-partner.google.com>,
        Stephen Boyd <swboyd@...omium.org>,
        Cong Yang <yangcong5@...qin.corp-partner.google.com>,
        Jitao Shi <jitao.shi@...iatek.com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Sam Ravnborg <sam@...nborg.org>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/4] drm/panel: boe-tv101wum-nl6: Drop surplus prepare tracking

Hi,

On Mon, Jul 3, 2023 at 6:22 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> The DRM panel core already keeps track of if the panel is already
> prepared so do not reimplement this.
>
> Reviewed-by: Sam Ravnborg <sam@...nborg.org>
> Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
> ---
>  drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 12 ------------
>  1 file changed, 12 deletions(-)

It does? Can you please point to where/when the DRM panel core keeps
track of this? I know I've posted a patch for this at:

https://lore.kernel.org/r/20230607144931.v2.2.I59b417d4c29151cc2eff053369ec4822b606f375@changeid

...but I haven't landed it because I'm still trying to get consensus
on the rest of the series and a later patch in the series depends on
it.

If you have some evidence that my patch isn't needed, can you please
point at it in the commit message? I would say at least that someone
else seemed to agree that the core wasn't checking this [1], though I
guess it's possible that person was running old code or was just as
confused as I was.

[1] https://lore.kernel.org/r/646e391f.810a0220.214ce.d680@mx.google.com

-Doug

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ