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] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM3PPF208195D8DA7D1DA361E677513D3BAE328A@DM3PPF208195D8D.namprd11.prod.outlook.com>
Date: Mon, 11 Aug 2025 11:16:36 +0000
From: "Kandpal, Suraj" <suraj.kandpal@...el.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, Laurent Pinchart
	<laurent.pinchart@...asonboard.com>
CC: "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>,
	"liviu.dudau@....com" <liviu.dudau@....com>,
	"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
	"mripard@...nel.org" <mripard@...nel.org>, "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

> > > @@ -2305,6 +2360,11 @@ struct drm_connector {
> > >  	 * @cec: CEC-related data.
> > >  	 */
> > >  	struct drm_connector_cec cec;
> > > +
> > > +	/**
> > > +	 * @writeback: Writeback related valriables.
> > > +	 */
> > > +	struct drm_writeback_connector writeback;
> >
> > No, sorry, that's a bad idea. Most connectors have nothing to do with
> > writeback, you shouldn't introduce writeback-specific fields here.
> > drm_writeback_connector happens to be a drm_connector because of
> > historical reasons (it was decided to reuse the connector API exposed
> > to userspace instead of exposing a completely separate API in order to
> > simplify the implementation), but that does not mean that every
> > connector is related to writeback.
> >
> > I don't know what issues the Intel driver(s) have with
> > drm_writeback_connector, but you shouldn't make things worse for
> > everybody due to a driver problem.
> 
> Suraj is trying to solve a problem that in Intel code every drm_connector must
> be an intel_connector too. His previous attempt resulted in a loose abstraction
> where drm_writeback_connector.base wasn't initialized in some cases (which is
> a bad idea IMO).
> 
> I know the historical reasons for drm_writeback_connector, but I think we can
> do better now.
> 
> So, I think, a proper approach would be:
> 
> struct drm_connector {
>     // other fields
> 
>     union {
>         struct drm_connector_hdmi hdmi; // we already have it
>         struct drm_connector_wb wb;  // this is new
>     };
> 
>     // rest of the fields.
> };
> 
> I plan to add drm_connector_dp in a similar way, covering DP needs (currently
> WIP).
> 

Right we are seeking to get an ACK on this design.

Regards,
Suraj Kandpal

> --
> With best wishes
> Dmitry