linux-kernel - Re: [PATCH v1] drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used

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

Message-ID: <CAD=FV=VvePQt9LgupM+hW72doRja4UPBj6sBXUh091yHFxcxVw@mail.gmail.com>
Date: Fri, 6 Feb 2026 08:27:07 -0800
From: Doug Anderson <dianders@...omium.org>
To: Francesco Dolcini <francesco@...cini.it>
Cc: Franz Schnyder <fra.schnyder@...il.com>, Andrzej Hajda <andrzej.hajda@...el.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>, 
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>, Jonas Karlman <jonas@...boo.se>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Franz Schnyder <franz.schnyder@...adex.com>, dri-devel@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v1] drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is
 not used

Hi,

On Fri, Feb 6, 2026 at 8:11 AM Francesco Dolcini <francesco@...cini.it> wrote:
>
> Hello Doug,
>
> On Fri, Feb 06, 2026 at 07:46:10AM -0800, Doug Anderson wrote:
> > On Fri, Feb 6, 2026 at 4:38 AM Franz Schnyder <fra.schnyder@...il.com> wrote:
> > >
> > > From: Franz Schnyder <franz.schnyder@...adex.com>
> > >
> > > Fallback to polling to detect hotplug events on systems without
> > > interrupts.
> > >
> > > On systems where the interrupt line of the bridge is not connected,
> > > the bridge cannot notify hotplug events. Only add the
> > > DRM_BRIDGE_OP_HPD flag if an interrupt has been registered
> > > otherwise remain in polling mode.
> > >
> > > Fixes: 9133bc3f0564 ("drm/bridge: ti-sn65dsi86: Add support for DisplayPort mode with HPD")
> > > Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
> > > Cc: stable@...r.kernel.org
> > > Signed-off-by: Franz Schnyder <franz.schnyder@...adex.com>
> > > ---
> > >  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++++--
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > It's weird that you have two fixes, but upon closer inspection, I see
> > why you tagged it as you did.
> >
> > The first commit that landed, commit 55e8ff842051 ("drm/bridge:
> > ti-sn65dsi86: Add HPD for DisplayPort connector type"), was still
> > using polling mode and just using the HPD line for polling. That
> > commit incorrectly set the flag "DRM_BRIDGE_OP_HPD". So the proper
> > backport to kernels with just that commit would be to take away that
> > flag. Unfortunately, I didn't notice this problem during the review
> > and I don't personally have any hardware using this bridge for DP,
> > only eDP.
> >
> > The second commit that landed, commit 9133bc3f0564 ("drm/bridge:
> > ti-sn65dsi86: Add support for DisplayPort mode with HPD"), actually
> > added support for the HPD interrupt. After this commit, your fix
> > (which makes the flag "DRM_BRIDGE_OP_HPD" depend on the IRQ) is the
> > correct one.
> >
> > Unfortunately, I think the above will confuse the stable scripts.
> > Since your patch applied cleanly atop the first commit then it will
> > picked to any kernels with it, even if they don't have the second
> > commit.
> >
> > I think the first commit landed in v6.16 and the second commit isn't
> > yet in any stable release.
> >
> > Maybe the right way to look at this is to just call the 2nd patch a
> > prereq? So this:
> >
> > Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for
> > DisplayPort connector type")
> > Cc: <stable@...r.kernel.org> # 6.16: 9133bc3f0564: drm/bridge: ti-sn65dsi86: Add
> >
> > That will cause the 2nd patch to get picked up for stable too, but
> > that would be preferable to having just your fix without the 2nd
> > patch. Alternatively, you could try to add some other note to the
> > stable team to help them arrive at the right backport.
>
> We had some internal review before sending this patch and I am the one
> that suggested to put both commit as fixes in the end.
>
> I agree that your solution is the correct one (I am not familiar with
> the syntax there, but I agree on the concept), assuming
> nobody disagree on this, should we send a v2, or are you going to amend
> the commit message when applying it?

You can see the docs at:

Documentation/process/stable-kernel-rules.rst

As long as you agree with what I came up with, there's no need for you
to resend and I can adjust it when I land the patch. I'll still let it
sit on the list for at least next week to give others a chance to
review / comment.

-Doug