Re: [PATCH] drm/panel: himax-hx83102: restore MODE_LPM after sending disable cmds

[Doug Anderson]

Hi,

On Tue, Apr 28, 2026 at 1:52 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
>
> > > > > > > > Cc: stable@xxxxxxxxxxxxxxx # 6.11+
> > > > > > > > Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102: Break out
> > > > > > > > as
> > > > > > > > separate driver")
> > > > > > >
> > > > > > > This "Fixes" looks wrong. The bug was still there even before
> > > > > > > the
> > > > > > > driver was broken out. ...and it looks like the driver that
> > > > > > > this
> > > > > > > was
> > > > > > > broken out of (panel-boe-tv101wum-nl6.c) still has the same
> > > > > > > bug?
> > > > > >
> > > > > > Yes, but I think the fix shouldn't be propagated to the other
> > > > > > driver
> > > > > > because of the same reason with breaking out the original
> > > > > > driver.
> > > > >
> > > > > ...but doesn't all the same logic apply to the other driver?
> > > > > Nothing
> > > > > ever adds MIPI_DSI_MODE_LPM back in.
> > > > >
> > > > > Even if you don't fix the other driver yourself right now, the
> > > > > proper
> > > > > "Fixes" tag is when the problem was introduced, not when the
> > > > > driver
> > > > > forked out.
> > > >
> > > > I think the Fixes tag should point to where the driver is forked
> > > > out,
> > > > and if I'm going to send a patch for panel-boe-tv101wum-nl6, it
> > > > will
> > > > has a Fixes tag pointing to the further commit affecting that
> > > > driver.
> > >
> > > You're free to have your own opinion, but that doesn't match my
> > > understanding of the Fixes tag. If you can convince Neil or some
> > > other
> > > drm-misc committer to land your changes with the Fixes tag as you
> > > have
> > > it, then I won't object, but I won't land it. Best of luck!
> >
> > I checked the forking commit, and the forking process doesn't involve
> > moving a `dsi->mode_flags &= ~MIPI_DSI_MODE_LPM` clause from the panel-
> > boe-tv101wum-nl6 driver to the panel-himax-hx83102 driver, which means
> > that this clause in the new driver is new, and shouldn't be trivially
> > backported to the old driver (because this process will affect other
> > non-hx83102 panels in that driver). Even if the unblanking issue exists
> > before the forking point, the specific code fixed by this commit is
> > created by the forking point (just by copying), instead of the previous
> > commit introducing the starry panel or the initial addition of the LPM
> > masking code to panel-boe-tv101wum-nl6 .
>
> In general in Linux drivers support more than one device. If you have
> a fix for a driver, then you make the fix. You don't couch your fix
> with "if (this_is_the_device_i_tested) do_my_fix()"
>
> Said another way, if we hadn't forked support of this panel into a
> separate driver, then you'd _have_ to be fixing to
> panel-boe-tv101wum-nl6 driver, correct? You wouldn't add a special
> case just for your panel--you'd fix it for the whole driver.
>
> Another argument here is that someone could (conceivably) still have
> an old kernel built from before the driver forked out. Maybe they care
> about supporting "panel-himax-hx83102" panels on their old kernel.
> They'd want the fix tagged so that they could find it.
>
>
> > In addition, this isn't a regression fix, so Fixes tag is only
> > informative for backporting. The previous paragraph has already proved
> > that pointing it further isn't meaningful for backporting.
>
> Sure, it's not a regression, but it's still a fix for a bug in the
> panel driver. I don't know why someone wouldn't want to backport it if
> they were using this panel.

I see you've now also got a fix for panel-boe-tv101wum-nl6.c [1]. If
that patch also lands, then IMO this becomes fine.

[1] https://lore.kernel.org/r/20260503091708.1079962-1-zhengxingda@xxxxxxxxxxx/

Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx>