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

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: <4ox7yh3i47odinoaalzjz7d3gvx36bxbaspo6qfvvvl3jqhdiv@24ownjco3ud2>
Date: Wed, 3 Sep 2025 15:30:47 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Heiko Stuebner <heiko@...ech.de>, Yury Norov <yury.norov@...il.com>
Cc: Andy Yan <andyshrk@....com>, mripard@...nel.org, neil.armstrong@...aro.org,
        andrzej.hajda@...el.com, jernej.skrabec@...il.com, jonas@...boo.se,
        Laurent.pinchart@...asonboard.com, maarten.lankhorst@...ux.intel.com,
        rfoss@...nel.org, simona@...ll.ch, tzimmermann@...e.de,
        knaerzche@...il.com, devicetree@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
        Andy Yan <andy.yan@...k-chips.com>
Subject: Re: [PATCH v7 1/2] drm/rockchip: inno-hdmi: Convert to drm bridge

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@...k-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@...k-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?

-- 
With best wishes
Dmitry