Re: [PATCH v7 1/2] drm/rockchip: inno-hdmi: Convert to drm bridge

From: Yury Norov <yury.norov@gmail.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Heiko Stuebner <heiko@sntech.de>, Andy Yan <andyshrk@163.com>,
	mripard@kernel.org, neil.armstrong@linaro.org,
	andrzej.hajda@intel.com, jernej.skrabec@gmail.com,
	jonas@kwiboo.se, Laurent.pinchart@ideasonboard.com,
	maarten.lankhorst@linux.intel.com, rfoss@kernel.org,
	simona@ffwll.ch, tzimmermann@suse.de, knaerzche@gmail.com,
	devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	Andy Yan <andy.yan@rock-chips.com>
Subject: Re: [PATCH v7 1/2] drm/rockchip: inno-hdmi: Convert to drm bridge
Date: Wed, 3 Sep 2025 17:01:14 -0400	[thread overview]
Message-ID: <aLismmDJfusG0x0Z@yury> (raw)
In-Reply-To: <4ox7yh3i47odinoaalzjz7d3gvx36bxbaspo6qfvvvl3jqhdiv@24ownjco3ud2>

On Wed, Sep 03, 2025 at 03:30:47PM +0300, Dmitry Baryshkov wrote:
> On Wed, Sep 03, 2025 at 01:59:51PM +0200, Heiko Stuebner wrote:
> > Hi Andy,
> > 
> > Am Mittwoch, 3. September 2025, 13:07:38 Mitteleuropäische Sommerzeit schrieb Andy Yan:
> > > From: Andy Yan <andy.yan@rock-chips.com>
> > > 
> > > Convert it to drm bridge driver, it will be convenient for us to
> > > migrate the connector part to the display driver later.
> > > 
> > > Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> > 
> > more like a general remark, this essentially conflicts with the
> > big hiword-cleanup [0] that was merged today, as the inno-hdmi driver
> > "lost" its separate HIWORD_UPDATE macro in favor a nicer generic one.
> > 
> > I'm not sure what the best way to proceed is, apart from waiting for
> > 6.18-rc1.
> 
> I'd say, the correct way to handle would have been to:
> - merge only FIELD_PREP_WM16 addition into bitmap-for-next using
>   immutable tag
> - merge the tag + all other patches into subsystem trees. Otherwise
>   that series can cause a lot of conflicts with all affected subsystems.
> 
> Yury, would it be possible to implement this plan instead of pulling
> everything through your tree?

Yeah, this is 100% technically correct way of moving things.

The problem is that driver maintainers are usually not quick taking
this type of changes. In my experience, if we merge #1 only, we'll
end up with just another flavor of HIWORD_UPDATE(), maybe adopted
by a couple of drivers.

This is exactly opposite to the original goal of the series: nice and
almost complete consolidation of scattered HIWORD_UPDATE() versions.

So far, there's the only conflict with the others, and Andy said he's
OK to hold his series.

I would prefer to have all those patches in bitmap-for-next for a while.
If there will be more conflicts, then yeah, I'll follow your route.
Otherwise, let's keep things as they are, and encourage developers to
test their patches against linux-next, as they normally should.

Thanks,
Yury