On Wed, Sep 03, 2025 at 05:01:14PM -0400, Yury Norov wrote: > 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....@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....@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.
Ack, thanks for the explanation. -- With best wishes Dmitry
