Re: "thunderbolt ... (DP): not active, tearing down" error breaking DP over thunderbolt displays

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

On Mon, Oct 26, 2026 at 03:22:06PM +0100, Hans de Goede wrote:
> Hi Mika,
> 
> On 26-Oct-26 1:37 PM, Mika Westerberg wrote:
> > Hi,
> > 
> > On Mon, Oct 26, 2026 at 11:48:06AM +0100, Hans de Goede wrote:
> 
> <snip>
> 
> >> p.s.
> >>
> >> We had a similar problem with deferred_probe_timeout handling, see:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/base/Kconfig?id=56e3ee721b33bdc4ce0765d370983aa4384f8a59
> >>
> >> there this was fixed by making the default timeout value a Kconfig
> >> option and letting distros override it since previous discussions
> >> did not lead to a consensus on how to handle this. But that won't
> >> work here if we want to deal with the "complication with add-in-cards
> >> that don't have all DP INs connected" case.
> >>
> >> I'm mentioning this because it shows there is a generic problem
> >> with this "timeout design pattern" trap us kernel devs seem to
> >> keep falling for, especially in relation to things not happening
> >> in the initramfs while it waits for user input causing all
> >> these timeouts to trigger while they should not trigger yet
> >> because more drivers will load once we switch to the real rootfs.
> >>
> >> This has made me thinking that maybe we need a bootup-done
> >> or at least switched-to-real-rootfs sysfs file userspace can
> >> write and only start timeouts like these once userspace has
> >> written that file?
> > 
> > Yes, I think this is the way to go forward. Then something (like
> > notification or callback) that drivers who are interested can opt-in.
> 
> I'm glad you like the idea.
> 
> There are some details which we need to work out. If we enable this
> unconditionally in the kernel then all timeouts based on this will
> only work if there is a new enough userspace to actually write
> 
> "rootfs-mouned" or "bootup-done" to:
> 
> /sys/kernel/boot-stage
> 
> So my suggestion would be that the initramfs itself will write:
> 
> "initramfs" to "/sys/kernel/boot-stage" early on and that activates
> this mechanism pausing any potential timeouts.

I wonder if using SYSTEM_RUNNING and the like here would do the trick? If
not then maybe adding one more state there?

> The problem with this approach though is that this means starting
> the timeouts as before, cancelling them on "initramfs" boot-stage
> and then re-starting them on "rootfs-mouned" or "bootup-done" .
> 
> With the cancelling bit feeling a bit icky, although I guess this
> could all be done with the same notifier depending on the notifier
> argument so this might not be too bad...

At least for TB I think we can start with the infinite and then once we get
some "notification" just modify the timeout to now + 12s or so. Not sure
about the other use cases though.

> ###
> 
> Once we've an API design we like, the problem becomes who is going
> to write the code for this and lead the attempt to get something
> like this upstream. I'm interested in this, but I also really do not
> have the time to work on this atm.

Yeah, I also don't have time to work on this right now.