On 6/9/2025 4:19 AM, Michał Pecio wrote:
Hi,
General remarks:
- broken threading on 1/2 and 2/2
- some Cc missing on individual patch emails
Yeah; sorry about that. I got bit by
https://github.com/kworkflow/kworkflow/issues/1207 once again. Once I
realized that happened I figured unthreaded was better than missing so I
ended off sending the missing ones to each of the lists that missed them.
If I send a v2 with them together again I'll just manually do to/cc for
everything.
On Sun, 8 Jun 2025 20:58:00 -0500, Mario Limonciello wrote:
When a USB4 or TBT3 dock is disconnected a lot of warnings and errors
are emitted related to the PCIe tunnels and XHCI controllers in th
dock.
These patches will probably also trigger on any loss of PCIe link for
any reason: badly seated card, worn connector, EMI, etc.
Will there be any remaining message about dead PCIe links, or just
a silent disappearence? Like dev_info("USB disconnect ...") in USB.
Good point on the PCIe patches with other failures. Those wouldn't have
any "hotplug event" though would they? This all stems from the hotplug
event, so would it be worth storing the state on the struct pci_dev to
conditionally show these PCIe messages?
The messages are loud, but it's mostly because the functions that
emit the messages don't check whether the device is actually alive.
The PCIe hotplug services mark the device as perm dead, so that
can be used to hide some of the messsages.
In the XHCI driver the device is marked as dying already, so that
can also be used to hide messages.
Are PCI drivers expected to stay silent on sudden removal mid operation?
Is there no "safe ejection" procedure for those Thunderbolt devices?
With docking surprise hot removal is a standard operation.
Userspace doesn't offer anything for a clean removal event of PCIe like
USB storage does.
Mario Limonciello (4):
PCI: Don't show errors on inaccessible PCI devices
PCI: Fix runtime PM usage count underflow
usb: xhci: Avoid showing errors during surprise removal
usb: xhci: Avoid showing warnings for dying controller
Regards,
Michal
