linux-kernel - Re: [RFT PATCH v2 00/48] 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]

Message-ID: <CACRpkdYbtfE9RLsDewV2UwnJknCp_sFEgc+cq=OF+Qd3tkTcwA@mail.gmail.com>
Date: Mon, 6 May 2024 08:52:39 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Douglas Anderson <dianders@...omium.org>
Cc: dri-devel@...ts.freedesktop.org, Maxime Ripard <mripard@...nel.org>, 
	Chris Morgan <macromorgan@...mail.com>, Yuran Pereira <yuran.pereira@...mail.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Daniel Vetter <daniel@...ll.ch>, 
	David Airlie <airlied@...il.com>, Guido Günther <agx@...xcpu.org>, 
	Jerry Han <hanxu5@...qin.corp-partner.google.com>, 
	Jessica Zhang <quic_jesszhan@...cinc.com>, Jonathan Corbet <corbet@....net>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Matthias Brugger <matthias.bgg@...il.com>, Ondrej Jirman <megi@....cz>, 
	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-arm-kernel@...ts.infradead.org, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-mediatek@...ts.infradead.org
Subject: Re: [RFT PATCH v2 00/48] drm/panel: Remove most store/double-check of
 prepared/enabled state

On Fri, May 3, 2024 at 11:36 PM Douglas Anderson <dianders@...omiumorg> 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.
>
> In response to my V1 series [1] we had much discussion of what to
> do. The conclusion was that as long as DRM modeset drivers properly
> called drm_atomic_helper_shutdown() that we should be able to remove
> the explicit shutdown/remove handling in the panel drivers. Most of
> the patches to improve DRM modeset drivers [2] [3] [4] have now
> landed.
>
> In contrast to my V1 series, I broke the V2 series up a lot
> more. Since a few of the panel drivers in V1 already landed, we had
> fewer total drivers and so we could devote a patch to each panel.
> Also, since we were now relying on DRM modeset drivers I felt like we
> should split the patches for each panel into two: one that's
> definitely safe and one that could be reverted if we found a
> problematic DRM modeset driver that we couldn't fix.
>
> Sorry for the large number of patches. I've set things to mostly just
> CC people on the cover letter and the patches that are relevant to
> them. I've tried to CC people on the whole series that have shown
> interest in this TODO item.
>
> As patches in this series are reviewed and/or tested they could be
> landed. There's really no ordering requirement for the series unless
> patches touch the same driver.
>
> NOTE: this touches _a lot_ of drivers, is repetitive, and is not
> really possible to generate automatically. That means it's entirely
> possible that my eyes glazed over and I did something wrong. Please
> double-check me and don't assume that I got everything perfect, though
> I did my best. 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.
>
> [1] https://lore.kernel.org/r/20230804140605.RFC.4.I930069a32baab6faf46d6b234f89613b5cec0f14@changeid
> [2] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org
> [3] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org
> [4] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org

This is the right thing to do, thanks for looking into this!

As for the behaviour of .remove() I doubt whether in many cases
the original driver authors have even tested this themselves.
I would say we should just apply the series as soon as it's non-RFC
after the next merge window and see what happens. I doubt it
will cause much trouble.

The series:
Acked-by: Linus Walleij <linus.walleij@...aro.org>

Yours,
Linus Walleij