Re: [PATCH] thunderbolt: Defer DP tunnel teardown until display driver is ready

[An Wu]

Hi Mario
 Thank you for your valuable advice. This approach could help us
overcome the current limitation of displaying the LUKS unlock screen
through a Thunderbolt dock.
It would also allow us to drop the patch for the timeout issue. I’ll
propose this change to the team.

For 2) and 3), I'll bring them up for the team to evaluate.

Thank you~

BR
    An

On Fri, Jul 17, 2026 at 2:32 AM Mario Limonciello
<mario.limonciello@xxxxxxx> wrote:
>
> Hi,
>
> I had a few thoughts while reading this thread I wanted to share.
>
> 1) Ubuntu builds the initramfs locally with dracut.
>
> It should be possible to know at the time of building the initramfs
> which hardware is actually on the system and only include the modules
> you need to avoid this issue.
>
> For example if you're on an I+N system you can avoid amdgpu and if
> you're on a pure I system you could avoid nouveau and amdgpu.  Does that
> help the size concerns for the initramfs?
>
> 2) Do you really need thunderbolt.ko in the initramfs for keyboards and
> the like to work?
>
> I don't think so.  I thought x86 UEFI laptops have a pre-OS connection
> manager that will remain resident until the OS connection manager takes
> over.  I know this is the case for AMD, and I think this also applies to
> Intel.
>
> 3) Are you including boltd in the initramfs?
>
> If not; you have a secondary problem you might not realize that defeats
> your entire goal of having USB keyboard connected to a dock working
> during LUKS.
>
> If the keyboard is connected to a USB3 controller behind a TBT3
> controller the USB4 router topology gets reset when thunderbolt.ko
> loads.  This is because the firmware often doesn't reserve enough memory
> for hotpluggable PCIe devices.  Linux resets it and assigns enough
> memory for this to work.  This is the same thing that Windows does.
>
> Well after that reset happens the TBT3 device won't be authorized
> meaning any PCIe topology behind it isn't authorized.  At runtime this
> is solved by boltd checking that the IOMMU is enabled (and was enabled
> Pre-BOO) in order to authorize the topology.
>
> I've raised something about this in the past, but AFAICT no one in
> Ubuntu looked at it.
>
> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2078573
>
> 4) This patch may have been dropped upstream, but I still see it
> included in Ubuntu's kernel.
>
> https://lists.ubuntu.com/archives/kernel-team/2026-June/168287.html
>
> What happens with NPI hardware that doesn't have a display driver ready?
>   It seems like this is going to cause thunderbolt.ko to infinitely
> reschedule work looking for one, wasting CPU cycles and otherwise
> blocking CPU low power states.
>
> Thus I don't think this is very good tech debt to adopt in Ubuntu's
> kernel when there are other technical solutions available to consider.
>
> On 6/5/26 05:16, An Wu wrote:
> > Hi Mika
> >      After further consideration, we've decided to drop this patch and
> > probably to note it as limitation. Really appreciate your patience and
> > sorry for the noise.
> >
> > BR
> >      An
> >
> > On Mon, Jun 1, 2026 at 4:18 PM An Wu <an.wu@xxxxxxxxxxxxx> wrote:
> >>
> >> Hi Mika
> >>      We tried putting graphic modules into initramfs and the size
> >> increased from 56 MB to over 200 MB. We will discuss with the team the
> >> possibility of fixing this in userspace and follow up once we have a
> >> clearer picture.
> >> Really appreciate your time and patience.
> >>
> >> BR
> >>      An
> >>
> >> On Mon, Jun 1, 2026 at 3:04 PM Mika Westerberg
> >> <mika.westerberg@xxxxxxxxxxxxxxx> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Mon, Jun 01, 2026 at 02:50:21PM +0800, An Wu wrote:
> >>>> Hi Mika
> >>>>
> >>>> Another approach I considered is using register_module_notifier() to
> >>>> detect when a display driver module is loaded, then retrigger the DP
> >>>> tunnel setup. However, since struct module does not carry any device
> >>>> class or subsystem metadata, there is no generic way to identify
> >>>> whether a loaded module is a display driver. We would need to maintain
> >>>> a hardcoded list of known GPU module names (i915, xe, amdgpu, etc.),
> >>>> which is fragile and not scalable.
> >>>
> >>> Indeed. Perhaps not to try to solve this in the kernel and instead do this
> >>> in userspace?
> >>>
> >>> Have you actually measured how much initramfs size "increases" if you do
> >>> include the relevant graphics drivers and their dependencies?
> >
>