linux-kernel - Re: [RFT PATCH v2 30/48] drm/panel: xinpeng-xpp055c272: Stop tracking prepared

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: <2324654.PIDvDuAF1L@diego>
Date: Mon, 06 May 2024 18:30:57 +0200
From: Heiko Stübner <heiko@...ech.de>
To: dri-devel@...ts.freedesktop.org, Maxime Ripard <mripard@...nel.org>,
 Douglas Anderson <dianders@...omium.org>
Cc: Linus Walleij <linus.walleij@...aro.org>,
 Chris Morgan <macromorgan@...mail.com>,
 Yuran Pereira <yuran.pereira@...mail.com>,
 Neil Armstrong <neil.armstrong@...aro.org>,
 Douglas Anderson <dianders@...omium.org>, Daniel Vetter <daniel@...ll.ch>,
 David Airlie <airlied@...il.com>, Jessica Zhang <quic_jesszhan@...cinc.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Sam Ravnborg <sam@...nborg.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 linux-kernel@...r.kernel.org
Subject:
 Re: [RFT PATCH v2 30/48] drm/panel: xinpeng-xpp055c272: Stop tracking
 prepared

Am Freitag, 3. Mai 2024, 23:33:11 CEST schrieb Douglas Anderson:
> 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.
> 
> Cc: "Heiko Stübner" <heiko@...ech.de>
> Signed-off-by: Douglas Anderson <dianders@...omium.org>

the underlying setup (rockchip-drm with dw-dsi) as well as the
change itself is similar to the ltk050h3146w variant, so I don't
see how this should behave differently ;-)

Reviewed-by: Heiko Stuebner <heiko@...ech.de>