thunderbolt: NHI resume routine

[obiwac]

Summary

This is meant as a stopgap solution to recreate the ring state on resume
such that we can re-suspend USB4 controllers.

Currently, these rings fill up as we are not correctly acknowledging
hotplug events, so the only way to re-suspend was to unload and reload
the tb kernel module. This is necessary for entry to deeper S0ix states
on some platforms.

Sponsored by: The FreeBSD Foundation

[ngie]

sys/dev/thunderbolt/nhi.c

414–418

How are upper layers, e.g., network layers, storage layers, etc, notified that their transmit/receives need to be requeued? Is this something that the hardware (NHI router) is expected to handle transparently, or is this something that needs to be handled by the thunderbolt(4) driver?
How does the thunderbolt(4) driver also tell consumers/producers that it's not routing any additional traffic after this function is called?

sys/dev/thunderbolt/router.c

433

Should this return an error?

[ngie]

sys/dev/thunderbolt/nhi.c

414–418

With respect to this comment...

How does the thunderbolt(4) driver also tell consumers/producers that it's not routing any additional traffic after this function is called?

... I remember from my embedded systems classes that sometimes drivers need to have specific registers programmed in order to tell the hardware to refuse any new messages. This is what I'm implying/trying to figure out with this line of questioning.