| 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
| ||
|
Message-ID: <YAIBxF2kiy0twoV+@pendragon.ideasonboard.com>
Date: Fri, 15 Jan 2021 22:57:40 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Maxime Ripard <maxime@...no.tech>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
Daniel Vetter <daniel.vetter@...el.com>,
David Airlie <airlied@...ux.ie>,
dri-devel@...ts.freedesktop.org,
Alexey Brodkin <abrodkin@...opsys.com>,
Daniel Vetter <daniel@...ll.ch>,
Liviu Dudau <liviu.dudau@....com>,
Brian Starkey <brian.starkey@....com>,
Sam Ravnborg <sam@...nborg.org>,
Boris Brezillon <bbrezillon@...nel.org>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Ludovic Desroches <ludovic.desroches@...rochip.com>,
Anitha Chrisanthus <anitha.chrisanthus@...el.com>,
Edmund Dea <edmund.j.dea@...el.com>,
Chun-Kuang Hu <chunkuang.hu@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Matthias Brugger <matthias.bgg@...il.com>,
Tomi Valkeinen <tomba@...nel.org>,
Dave Airlie <airlied@...hat.com>,
Gerd Hoffmann <kraxel@...hat.com>,
Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
Maxime Ripard <mripard@...nel.org>,
Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...l.net>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Hans de Goede <hdegoede@...hat.com>,
Rodrigo Siqueira <rodrigosiqueiramelo@...il.com>,
Melissa Wen <melissa.srw@...il.com>,
Haneen Mohammed <hamohammed.sa@...il.com>,
VMware Graphics <linux-graphics-maintainer@...are.com>,
Roland Scheidegger <sroland@...are.com>,
Hyun Kwon <hyun.kwon@...inx.com>,
Michal Simek <michal.simek@...inx.com>,
Shawn Guo <shawnguo@...nel.org>, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
virtualization@...ts.linux-foundation.org,
spice-devel@...ts.freedesktop.org,
linux-renesas-soc@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH 07/10] drm: Store new plane state in a variable for
atomic_update and disable
Hi Maxime,
Thank you for the patch.
On Fri, Jan 15, 2021 at 01:56:59PM +0100, Maxime Ripard wrote:
> In order to store the new plane state in a subsequent helper, let's move
> the plane->state dereferences into a variable.
>
> This was done using the following coccinelle script, plus some hand
> changes for vmwgfx:
>
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
>
> (
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_disable = func,
> ...,
> };
> |
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_update = func,
> ...,
> };
> )
>
> @ has_new_state_old_state @
> identifier plane_atomic_func.func;
> identifier plane;
> identifier new_state;
> symbol old_state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *old_state)
> {
> ...
> struct drm_plane_state *new_state = plane->state;
> ...
> }
>
> @ depends on !has_new_state_old_state @
> identifier plane_atomic_func.func;
> identifier plane;
> symbol old_state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *old_state)
> {
> + struct drm_plane_state *new_state = plane->state;
> <+...
> - plane->state
> + new_state
> ...+>
> }
>
> @ has_new_state_state @
> identifier plane_atomic_func.func;
> identifier plane;
> identifier new_state;
> symbol state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *state)
> {
> ...
> struct drm_plane_state *new_state = plane->state;
> ...
> }
>
> @ depends on !has_new_state_state @
> identifier plane_atomic_func.func;
> identifier plane;
> symbol state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *state)
> {
> + struct drm_plane_state *new_plane_state = plane->state;
> <+...
> - plane->state
> + new_plane_state
> ...+>
> }
>
> @ has_new_state_old_s @
> identifier plane_atomic_func.func;
> identifier plane;
> identifier new_state;
> symbol old_s;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *old_s)
> {
> ...
> struct drm_plane_state *new_state = plane->state;
> ...
> }
>
> @ depends on !has_new_state_old_s @
> identifier plane_atomic_func.func;
> identifier plane;
> symbol old_s;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *old_s)
> {
> + struct drm_plane_state *new_s = plane->state;
> <+...
> - plane->state
> + new_s
> ...+>
> }
I may have taken this as an opportunity to align naming conventions for
variables across drivers, but that may just be me.
>
> Signed-off-by: Maxime Ripard <maxime@...no.tech>
> ---
[snip]
> drivers/gpu/drm/omapdrm/omap_plane.c | 5 ++-
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 5 ++-
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +-
> drivers/gpu/drm/xlnx/zynqmp_disp.c | 7 ++--
For these, with the small issue below addressed,
Reviewed-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
[snip]
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c b/drivers/gpu/drm/omapdrm/omap_plane.c
> index 1042e1147e74..de5ad69af4cb 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -88,11 +88,12 @@ static void omap_plane_atomic_update(struct drm_plane *plane,
> static void omap_plane_atomic_disable(struct drm_plane *plane,
> struct drm_plane_state *old_state)
> {
> + struct drm_plane_state *new_state = plane->state;
> struct omap_drm_private *priv = plane->dev->dev_private;
> struct omap_plane *omap_plane = to_omap_plane(plane);
>
> - plane->state->rotation = DRM_MODE_ROTATE_0;
> - plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
> + new_state->rotation = DRM_MODE_ROTATE_0;
> + new_state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
> ? 0 : omap_plane->id;
Can you fix the indentation ?
> dispc_ovl_enable(priv->dispc, omap_plane->id, false);
[snip]
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists