linux-kernel - Re: [RFC PATCH 00/10] drm/panel: Remove most store/double-check of prepared/enabled state

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:   Tue, 5 Sep 2023 12:15:19 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     dri-devel@...ts.freedesktop.org,
        Maxime Ripard <mripard@...nel.org>,
        Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...il.com>,
        Guido Günther <agx@...xcpu.org>,
        Javier Martinez Canillas <javierm@...hat.com>,
        Jerry Han <hanxu5@...qin.corp-partner.google.com>,
        Jianhua Lu <lujianhua000@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Ondrej Jirman <megi@....cz>, Ondrej Jirman <megous@...ous.com>,
        Purism Kernel Team <kernel@...i.sm>,
        Robert Chiras <robert.chiras@....com>,
        Sam Ravnborg <sam@...nborg.org>,
        Stefan Mavrodiev <stefan@...mex.com>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 00/10] drm/panel: Remove most store/double-check of
 prepared/enabled state

Hi,

On Thu, Aug 10, 2023 at 1:23 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Fri, Aug 4, 2023 at 11:07 PM Douglas Anderson <dianders@...omium.org> wrote:
>
> > As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> > prepared/enabled in drm_panel"), we want to remove needless code from
> > panel drivers that was storing and double-checking the
> > prepared/enabled state. Even if someone was relying on the
> > double-check before, that double-check is now in the core and not
> > needed in individual drivers.
> >
> > This series attempts to do just that. While the original grep, AKA:
> >   git grep 'if.*>prepared' -- drivers/gpu/drm/panel
> >   git grep 'if.*>enabled' -- drivers/gpu/drm/panel
> > ...still produces a few hits after my series, they are _mostly_ all
> > gone. The ones that are left are less trivial to fix.
> >
> > One of the main reasons that many panels probably needed to store and
> > double-check their prepared/enabled appears to have been to handle
> > shutdown and/or remove. Panels drivers often wanted to force the power
> > off for panels in these cases and this was a good reason for the
> > double-check. As part of this series a new helper is added that uses
> > the state tracking that the drm_panel core is doing so each individual
> > panel driver doesn't need to do it.
> >
> > This series changes a lot of drivers and obviously the author can't
> > test on all of them. The changes here are also not completely trivial
> > in all cases. Please double-check your drivers carefully to make sure
> > something wasn't missed. After looking at over 40 drivers I'll admit
> > that my eyes glazed over a little.
> >
> > I've attempted to organize these patches like to group together panels
> > that needed similar handling. Panels that had code that didn't seem to
> > match anyone else got their own patch. I made judgement calls on what
> > I considered "similar".
> >
> > As noted in individual patches, there are some cases here where I
> > expect behavior to change a little bit. I'm hoping these changes are
> > for the better and don't cause any problems. Fingers crossed.
> >
> > I have at least confirmed that "allmodconfig" for arm64 doesn't fall
> > on its face with this series. I haven't done a ton of other testing.
>
> The series:
> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
>
> Please send out a non-RFC version, this is clearly the right thing to
> do.

As per the long discussion in response to patch #4, I think there are
still open questions about the later patches in this series. However,
I could land patches #1 - #3 if there are no concerns. Would anyone
object if I just landed them straight from this series with Linus's
review, or would I need to repost just patches #1 - #3 without the
"RFC" tag?

Thanks!

-Doug