Hi,

On systems with Full Disk Encryption (LUKS), the Thunderbolt driver
loads from initramfs early in boot and discovers the BIOS-established
DP tunnel. It starts DPRX polling, waiting for the GPU driver to read
DPCD from the connected monitor so the router firmware can set the
DPRX_DONE bit. However, the GPU driver resides on the encrypted root
filesystem and cannot load until the user enters the passphrase --
which takes an unbounded amount of time.

The 12-second DPRX timeout fires, and tb_dp_resource_unavailable()
permanently removes the DP IN adapter from dp_resources. The external
display stays blank with no software recovery path -- only physically
re-plugging the dock brings it back.

This patch defers the DP tunnel teardown when no PCI display driver
has bound yet. At DPRX timeout, we check whether any PCI display
class (0x03xx) device has a driver. If not, the tunnel is torn down
but the DP IN resource is kept in the available list. A PCI bus
notifier watches for BUS_NOTIFY_BOUND_DRIVER on display class
devices. When the GPU driver eventually binds, the notifier
schedules a work item that calls tb_tunnel_dp() to re-establish
the connection. By that point the GPU has already read DPCD during
its probe, so DPRX_DONE is already set and the tunnel activates
immediately.

If a display driver is already bound when the timeout fires, the
existing teardown behavior is preserved -- this indicates a real
failure (bad cable, disconnected display, etc.) rather than a
timing issue.

Considerations:

 - All GPU drivers on x86 (i915, xe, amdgpu, nouveau) register as
   PCI drivers with base class 0x03, so a single PCI bus notifier
   covers all vendors with no GPU driver changes needed.

 - The notifier fires after probe() succeeds (BUS_NOTIFY_BOUND_DRIVER),
   which means the GPU has already initialized the display engine and
   performed DPCD reads -- the retry succeeds immediately.

 - On suspend/resume the existing tunnel re-establishment paths are
   used; this patch only affects the initial boot timing issue.

Testing:

 - Hardware: Dell Pro Max 14 MC14250, Dell SD25TB5
   Thunderbolt 5 Dock, external BenQ monitor, LUKS full disk
   encryption.

 - Reproduced the issue: TB loaded at T+1s, DPRX teardown at
   T+14s, i915 loaded at T+84s, display blank.

 - With the patch: TB loaded at T+1s, DPRX timeout at T+14s
   printed "not active, deferring until display driver loads",
   i915 loaded at T+72s, notifier triggered retry, display
   came up successfully.

 - Also tested with i915 blacklisted at boot and loaded via a
   systemd service after a 30-second delay to simulate the FDE
   gap in a controlled way. The 58-second gap between timeout
   and GPU loading was handled correctly.

 - Verified that dock hotplug (GPU already loaded) still works
   normally -- the display_bound flag is true and the existing
   code path is taken.

ChunAn Wu (1):
  thunderbolt: Defer DP tunnel teardown until display driver is ready

 drivers/thunderbolt/tb.c | 97 ++++++++++++++++++++++++++++++++++------
 1 file changed, 89 insertions(+), 8 deletions(-)

-- 
2.34.1