linux-kernel - Re: [RFC PATCH 1/8] drm: writeback: Refactor drm_writeback

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] [day] [month] [year] [list]
Message-ID: <wr76vyag2osox2xf7ducnkiaanzk2k5ehd2ahnoyqdm5qiywlk@penf4v5bvg5z>
Date: Tue, 19 Aug 2025 11:03:52 +0200
From: "mripard@...nel.org" <mripard@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: "liviu.dudau@....com" <liviu.dudau@....com>, 
	"Kandpal, Suraj" <suraj.kandpal@...el.com>, Laurent Pinchart <laurent.pinchart@...asonboard.com>, 
	"kernel-list@...pberrypi.com" <kernel-list@...pberrypi.com>, "amd-gfx@...ts.freedesktop.org" <amd-gfx@...ts.freedesktop.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>, "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>, 
	"freedreno@...ts.freedesktop.org" <freedreno@...ts.freedesktop.org>, 
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, 
	"intel-xe@...ts.freedesktop.org" <intel-xe@...ts.freedesktop.org>, 
	"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>, "Nautiyal, Ankit K" <ankit.k.nautiyal@...el.com>, 
	"Murthy, Arun R" <arun.r.murthy@...el.com>, "Shankar, Uma" <uma.shankar@...el.com>, 
	"Nikula, Jani" <jani.nikula@...el.com>, "harry.wentland@....com" <harry.wentland@....com>, 
	"siqueira@...lia.com" <siqueira@...lia.com>, "alexander.deucher@....com" <alexander.deucher@....com>, 
	"christian.koenig@....com" <christian.koenig@....com>, "airlied@...il.com" <airlied@...il.com>, 
	"simona@...ll.ch" <simona@...ll.ch>, 
	"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>, "robin.clark@....qualcomm.com" <robin.clark@....qualcomm.com>, 
	"abhinav.kumar@...ux.dev" <abhinav.kumar@...ux.dev>, "tzimmermann@...e.de" <tzimmermann@...e.de>, 
	"jessica.zhang@....qualcomm.com" <jessica.zhang@....qualcomm.com>, "sean@...rly.run" <sean@...rly.run>, 
	"marijn.suijten@...ainline.org" <marijn.suijten@...ainline.org>, "mcanal@...lia.com" <mcanal@...lia.com>, 
	"dave.stevenson@...pberrypi.com" <dave.stevenson@...pberrypi.com>, 
	"tomi.valkeinen+renesas@...asonboard.com" <tomi.valkeinen+renesas@...asonboard.com>, 
	"kieran.bingham+renesas@...asonboard.com" <kieran.bingham+renesas@...asonboard.com>, "louis.chauvet@...tlin.com" <louis.chauvet@...tlin.com>
Subject: Re: [RFC PATCH 1/8] drm: writeback: Refactor drm_writeback_connector
 structure

Hi,

On Sat, Aug 16, 2025 at 01:20:53AM +0300, Dmitry Baryshkov wrote:
> On Thu, Aug 14, 2025 at 05:13:54PM +0100, liviu.dudau@....com wrote:
> > Hi,
> > 
> > On Wed, Aug 13, 2025 at 10:04:22AM +0000, Kandpal, Suraj wrote:
> > > > > > };
> > > > >
> > > > > I still don't like that. This really doesn't belong here. If anything,
> > > > > the drm_connector for writeback belongs to drm_crtc.
> > > > 
> > > > Why? We already have generic HDMI field inside drm_connector. I am really
> > > > hoping to be able to land DP parts next to it. In theory we can have a DVI-
> > > > specific entry there (e.g. with the subconnector type).
> > > > The idea is not to limit how the drivers subclass those structures.
> > > > 
> > > > I don't see a good case why WB should deviate from that design.
> > > > 
> > > > > If the issue is that some drivers need a custom drm_connector
> > > > > subclass, then I'd rather turn the connector field of
> > > > > drm_writeback_connector into a pointer.
> > > > 
> > > > Having a pointer requires additional ops in order to get drm_connector from
> > > > WB code and vice versa. Having drm_connector_wb inside drm_connector
> > > > saves us from those ops (which don't manifest for any other kind of structure).
> > > > Nor will it take any more space since union will reuse space already taken up by
> > > > HDMI part.
> > > > 
> > > > >
> > > 
> > > Seems like this thread has died. We need to get a conclusion on the design.
> > > Laurent do you have any issue with the design given Dmitry's explanation as to why this
> > > Design is good for drm_writeback_connector.
> > 
> > I'm with Laurent here. The idea for drm_connector (and a lot of drm structures) are to
> > be used as base "classes" for extended structures. I don't know why HDMI connector ended
> > up inside drm_connector as not all connectors have HDMI functionality, but that's a cleanup
> > for another day.
> 
> Maybe Maxime can better comment on it, but I think it was made exactly
> for the purpose of not limiting the driver's design. For example, a lot
> of drivers subclass drm_connector via drm_bridge_connector. If
> struct drm_connector_hdmi was a wrapper around struct drm_connector,
> then it would have been impossible to use HDMI helpers for bridge
> drivers, while current design freely allows any driver to utilize
> corresponding library code.

That's exactly why we ended up like this. With that design, we wouldn't
have been able to "inherit" two connector "classes": bridge_connector is
one, intel_connector another one.

See here for the rationale:
https://lore.kernel.org/dri-devel/ZOTDKHxn2bOg+Xmg@phenom.ffwll.local/

I don't think the "but we'll bloat drm_connector" makes sense either.
There's already a *lot* of things that aren't useful to every connector
(fwnode, display_info, edid in general, scaling, vrr, etc.)

And it's not like we allocate more than a handful of them during a
system's life.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)