linux-kernel - Re: [PATCH 06/29] drm/bridge: Implement atomic_print

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: <20250902202212.GU13448@pendragon.ideasonboard.com>
Date: Tue, 2 Sep 2025 22:22:12 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Thomas Zimmermann <tzimmermann@...e.de>
Cc: Maxime Ripard <mripard@...nel.org>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Andrzej Hajda <andrzej.hajda@...el.com>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	Robert Foss <rfoss@...nel.org>, Jonas Karlman <jonas@...boo.se>,
	Jernej Skrabec <jernej.skrabec@...il.com>,
	Jyri Sarha <jyri.sarha@....fi>,
	Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
	Devarsh Thakkar <devarsht@...com>, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/29] drm/bridge: Implement atomic_print_state

On Tue, Sep 02, 2025 at 03:22:40PM +0200, Thomas Zimmermann wrote:
> Am 02.09.25 um 10:32 schrieb Maxime Ripard:
> > Bridges have some fields in their state worth printing, but we don't
> > provide an atomic_print_state implementation to show those fields.
> >
> > Let's do so.
> >
> > Signed-off-by: Maxime Ripard <mripard@...nel.org>
> > ---
> >   drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
> >   1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index dd439d55177a867acb7ab73c02182bada44d93c9..e803dfd8fd5aae9c16931445213df04d8715b9f6 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -370,13 +370,31 @@ drm_bridge_atomic_destroy_priv_state(struct drm_private_obj *obj,
> >   	struct drm_bridge *bridge = drm_priv_to_bridge(obj);
> >   
> >   	bridge->funcs->atomic_destroy_state(bridge, state);
> >   }
> >   
> > +static void
> > +drm_bridge_atomic_print_priv_state(struct drm_printer *p,
> > +				   const struct drm_private_state *s)
> > +{
> > +	const struct drm_bridge_state *state =
> > +		container_of_const(s, struct drm_bridge_state, base);
> 
> Maybe adopt drm_priv_to_bridge_state() to accept const pointers?
> 
> https://elixir.bootlin.com/linux/v6.16.4/source/include/drm/drm_atomic.h#L1236

container_of_const() can helper, but drm_priv_to_bridge_state() will
need to be turned into a macro.

> > +	struct drm_bridge *bridge = drm_priv_to_bridge(s->obj);
> > +
> > +	drm_printf(p, "bridge: %s", drm_get_connector_type_name(bridge->type));

It would be nice to identify the bridge more precisely, but bridges have
no object ID :-/ The raw pointer may not be very useful. I wonder if we
should give an object ID to drm_private_obj instances, even if we don't
expose them to userspace. That's not a topic for this series of course.

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>

> > +	drm_printf(p, "\tinput bus configuration:");
> > +	drm_printf(p, "\t\tcode: %04x", state->input_bus_cfg.format);
> > +	drm_printf(p, "\t\tflags: %08x", state->input_bus_cfg.flags);
> > +	drm_printf(p, "\toutput bus configuration:");
> > +	drm_printf(p, "\t\tcode: %04x", state->output_bus_cfg.format);
> > +	drm_printf(p, "\t\tflags: %08x", state->output_bus_cfg.flags);
> > +}
> > +
> >   static const struct drm_private_state_funcs drm_bridge_priv_state_funcs = {
> >   	.atomic_duplicate_state = drm_bridge_atomic_duplicate_priv_state,
> >   	.atomic_destroy_state = drm_bridge_atomic_destroy_priv_state,
> > +	.atomic_print_state = drm_bridge_atomic_print_priv_state,
> >   };
> >   
> >   static bool drm_bridge_is_atomic(struct drm_bridge *bridge)
> >   {
> >   	return bridge->funcs->atomic_reset != NULL;
> >

-- 
Regards,

Laurent Pinchart