From: Mario Limonciello <superm1@kernel.org>
To: "Michał Pecio" <michal.pecio@gmail.com>,
"Rodrigo Siqueira" <siqueira@igalia.com>
Cc: mario.limonciello@amd.com, bhelgaas@google.com,
gregkh@linuxfoundation.org, mathias.nyman@intel.com,
linux-pci@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH 0/4] Don't make noise about disconnected USB4 devices
Date: Mon, 9 Jun 2025 08:05:36 -0500 [thread overview]
Message-ID: <18e93f06-ad5f-4335-8646-ce51cbdb783c@kernel.org> (raw)
In-Reply-To: <20250609111913.55153009@foxbook>
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
next prev parent reply other threads:[~2025-06-09 13:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 1:58 [PATCH 0/4] Don't make noise about disconnected USB4 devices Mario Limonciello
2025-06-09 1:58 ` [PATCH 3/4] usb: xhci: Avoid showing errors during surprise removal Mario Limonciello
2025-06-09 12:42 ` Mathias Nyman
2025-06-09 13:07 ` Mario Limonciello
2025-06-09 14:52 ` Mathias Nyman
2025-06-09 1:58 ` [PATCH 4/4] usb: xhci: Avoid showing warnings for dying controller Mario Limonciello
2025-06-09 12:47 ` Mathias Nyman
2025-06-09 9:19 ` [PATCH 0/4] Don't make noise about disconnected USB4 devices Michał Pecio
2025-06-09 13:05 ` Mario Limonciello [this message]
2025-06-09 15:20 ` Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18e93f06-ad5f-4335-8646-ce51cbdb783c@kernel.org \
--to=superm1@kernel.org \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mathias.nyman@intel.com \
--cc=michal.pecio@gmail.com \
--cc=siqueira@igalia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).