[PATCH v2 0/1] thunderbolt: Defer DP tunnel teardown until display driver is ready

[ChunAn Wu]

Hi Mika,

We encountered an issue where an external monitor connected through a
Thunderbolt dock (Dell SD25TB5) fails to display when the laptop boots
with the dock already connected and the lid closed.

Problem
=======

When the Thunderbolt driver loads early during boot (from initramfs at
~T+1s), it discovers the BIOS-established DP tunnel and begins polling
the DPRX_DONE bit to verify the tunnel is active. This polling has a
12-second timeout (TB_DPRX_TIMEOUT).

However, DPRX_DONE is only set after the display driver (e.g. i915)
loads and reads the monitor's DPCD via the AUX channel. On systems with
Full Disk Encryption (LUKS), the GPU driver does not load until the
passphrase is entered — often 60-90 seconds after boot. By that time,
the DPRX timeout has long expired and the DP tunnel is torn down via
tb_dp_resource_unavailable(), which permanently removes the DP IN port
from the dp_resources list. Recovery requires a physical re-plug.

This is a driver load ordering issue: the Thunderbolt driver assumes the
display driver is available within 12 seconds, but with FDE that
assumption does not hold.

Solution
========

This patch adds a PCI bus notifier that watches for display driver bind
events (PCI base class 0x03). When the DPRX timeout expires:

  - If a display driver is already bound: tear down as before (the
    tunnel is genuinely broken).
  - If no display driver has bound yet: call
    tb_deactivate_and_free_tunnel() to free the tunnel resources, but
    keep the DP IN port in the dp_resources list so it remains available
    for retry.

When a display driver eventually binds, the PCI bus notifier fires and
schedules work to call tb_tunnel_dp(), which re-establishes the DP
tunnel. Since BUS_NOTIFY_BOUND_DRIVER fires after the driver's probe()
has succeeded, the display engine is already initialized and DPRX_DONE
is set — the retry succeeds immediately.

Considerations
==============

We considered several alternative approaches:

  1. Increasing dprx_timeout: problematic with FDE since the passphrase
     wait time is unbounded. Any fixed timeout could be insufficient.

  2. Loading the GPU driver in initramfs: works but impractical as a
     general solution — it would require including every possible GPU
     driver in every initramfs image.

  3. Cross-driver notification from each GPU driver: requires modifying
     every GPU driver, which is not scalable.

The PCI bus notifier approach is self-contained within the Thunderbolt
driver, covers all PCI display devices (VGA, XGA, 3D controller, and
other display controllers under class 0x03xx), and handles the
unbounded delay case gracefully.

Testing
=======

Tested on Dell Pro Max 14 (MC14250) with Intel Meteor Lake GPU and Dell
SD25TB5 Thunderbolt 5 Dock, Ubuntu kernel 6.17.0-1023-oem, Secure Boot
enabled, LUKS Full Disk Encryption.

  - Without patch: DP tunnel torn down at T+14s, external display
    remains blank after i915 loads at T+84s. Only physical re-plug
    recovers.

  - With patch (i915 artificially delayed by 30s to simulate FDE):
    "not active, deferring until display driver loads" at T+14s,
    i915 loads at T+188s, PCI notifier triggers retry, DP tunnel
    re-established, external display lights up successfully.

  - With patch (normal boot, no delay): no behavioral change, display
    works as expected.

Changes in v2:
  - Fixed patch numbering (now [PATCH v2 1/1])

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

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

-- 
2.34.1