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

[Mario Limonciello]

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?