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 <[email protected]> wrote: > > > > From: Franz Schnyder <[email protected]> > > > > 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: [email protected] > > Signed-off-by: Franz Schnyder <[email protected]> > > --- > > 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: <[email protected]> # 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
