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

Message-ID: <CAD=FV=UO3wHqGKep67pY04PgBJKgvOgDf8u1qxeXmWkgVMLXiQ@mail.gmail.com>
Date: Fri, 6 Feb 2026 07:46:10 -0800
From: Doug Anderson <dianders@...omium.org>
To: Franz Schnyder <fra.schnyder@...il.com>
Cc: 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, Francesco Dolcini <francesco@...cini.it>, 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 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.

In any case:

Reviewed-by: Douglas Anderson <dianders@...omium.org>

I'm going to let this sit on the lists for a little while in case
folks want to comment on the above.

-Doug