From: Franz Schnyder <franz.schnyder@toradex.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@vger.kernel.org
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 276d05d25ad8..98d64ad791d0 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1415,6 +1415,7 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev,
 {
 	struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
 	struct device_node *np = pdata->dev->of_node;
+	const struct i2c_client *client = to_i2c_client(pdata->dev);
 	int ret;
 
 	pdata->next_bridge = devm_drm_of_get_bridge(&adev->dev, np, 1, 0);
@@ -1433,8 +1434,9 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev,
 			   ? DRM_MODE_CONNECTOR_DisplayPort : DRM_MODE_CONNECTOR_eDP;
 
 	if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) {
-		pdata->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT |
-				    DRM_BRIDGE_OP_HPD;
+		pdata->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT;
+		if (client->irq)
+			pdata->bridge.ops |= DRM_BRIDGE_OP_HPD;
 		/*
 		 * If comms were already enabled they would have been enabled
 		 * with the wrong value of HPD_DISABLE. Update it now. Comms
-- 
2.43.0

Hi,

On Fri, Feb 6, 2026 at 4:38 AM Franz Schnyder <fra.schnyder@gmail.com> wrote:
>
> From: Franz Schnyder <franz.schnyder@toradex.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@vger.kernel.org
> Signed-off-by: Franz Schnyder <franz.schnyder@toradex.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@vger.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@chromium.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

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@gmail.com> wrote:
> >
> > From: Franz Schnyder <franz.schnyder@toradex.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@vger.kernel.org
> > Signed-off-by: Franz Schnyder <franz.schnyder@toradex.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@vger.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?

Thanks,
Francesco

Hi,

On Fri, Feb 6, 2026 at 8:11 AM Francesco Dolcini <francesco@dolcini.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@gmail.com> wrote:
> > >
> > > From: Franz Schnyder <franz.schnyder@toradex.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@vger.kernel.org
> > > Signed-off-by: Franz Schnyder <franz.schnyder@toradex.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@vger.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