From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 296FC211F; Mon, 4 Aug 2025 00:31:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754267505; cv=none; b=RI1UZOtUMrgxXNrl2j9IweD/pOTErCIrNLFJXCPthwUInCUk7ZY7ziizQLOiVpGo8JXw30zU62DMIUftDUfiNydCBa6lQ6jQhMe/NlcWPFwJA6zpU25Rx3NDe0CwmbGewF3mQeaQqkeuuBn+STN3r1KDvzSSDOVzIsOlIVft4u4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754267505; c=relaxed/simple; bh=hQYVG7MBPq/lYAi3ZcX7k7xnBgWQPlhgZtYUUnLzYt0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=hqNERslhnvGymESmtZ5Zin+8cKAAgv/hC+iViksGSDzNuYax7gNNbIOnU0Vj+rEZFnyW1dckbExMU2ojaEXvuZvhZTkXe0vgMuOgvmFIVCC+hEeT3JV2wwGROgMbBiWK1zPEEDZbUBdVNG4g4PY5OclRW9TJyAgnlrSYuEurml8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hFIFGL1h; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hFIFGL1h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95F70C4CEF0; Mon, 4 Aug 2025 00:31:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754267505; bh=hQYVG7MBPq/lYAi3ZcX7k7xnBgWQPlhgZtYUUnLzYt0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hFIFGL1hQF2JM313KtSGvE8CHpNSXQ55fuQCQAMXOP9xZHOX4EDBiN68j/FQQpCPP OppUMnzEWGbSS0lUf1cMVlmjkmcHcrrMmjbrb5oZv7VexT/NV9BFYg126M8MY3R5hL 3XrIIlGJsi8DaiJG6YjhhbWwlhb3iMN9LMzGckbhkecuepzL/kRMoWjRiYMuBJU6wY 9Noh/aAO+FAvRvAc5SEwaqks5hZ7PBdo/TdVZnPpbZo9PpJpng1qwAnjrjMLTDqyk2 h7MDFgkHZEAE4z1SyM+7NKNqd/P24BGo9GkCeeZQEsHRV4OWZF0+hbYQf++qDkiq/n OAJ731eriEgNg== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Mario Limonciello , Mathias Nyman , Greg Kroah-Hartman , Sasha Levin , mathias.nyman@intel.com, linux-usb@vger.kernel.org Subject: [PATCH AUTOSEL 6.12 09/69] usb: xhci: Avoid showing errors during surprise removal Date: Sun, 3 Aug 2025 20:30:19 -0400 Message-Id: <20250804003119.3620476-9-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250804003119.3620476-1-sashal@kernel.org> References: <20250804003119.3620476-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.12.41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Mario Limonciello [ Upstream commit 4b9c60e440525b729ac5f071e00bcee12e0a7e84 ] When a USB4 dock is unplugged from a system it won't respond to ring events. The PCI core handles the surprise removal event and notifies all PCI drivers. The XHCI PCI driver sets a flag that the device is being removed as well. When that flag is set don't show messages in the cleanup path for marking the controller dead. Signed-off-by: Mario Limonciello Signed-off-by: Mathias Nyman Acked-by: Mathias Nyman Link: https://lore.kernel.org/r/20250717073107.488599-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Now let me analyze this commit properly: **Backport Status: YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Fixes a user-visible issue**: The commit addresses spurious error messages that appear when USB4 docks are unplugged. The original code shows `xhci_err(xhci, "xHCI host controller not responding, assume dead\n")` even during expected surprise removals, which can confuse users and fill system logs unnecessarily. 2. **Small and contained fix**: The change is minimal - it only adds a local `notify` variable and conditionalizes two operations based on whether the device is being removed: - The error message printing (line 1384 → lines 1379-1381) - The `usb_hc_died()` notification (reusing the same condition) 3. **No architectural changes**: This is a simple behavioral fix that doesn't modify any data structures, APIs, or core functionality. It merely suppresses error messages during an expected removal scenario. 4. **Clear bug fix**: The commit clearly fixes an issue where error messages are shown during normal USB4 dock removal operations. When `XHCI_STATE_REMOVING` is set (indicating PCI removal is in progress), the error message is now suppressed since it's an expected condition. 5. **Low risk of regression**: The change only affects logging behavior and maintains the same functional flow. The `usb_hc_died()` call was already conditional on `!XHCI_STATE_REMOVING`, so this commit just applies the same logic to the error message. 6. **Improves user experience**: USB4/Thunderbolt docks are increasingly common, and users frequently unplug them. Avoiding spurious error messages during normal operations is important for user experience and log clarity. The commit follows stable tree rules by being a minimal fix for a real issue that affects users, without introducing new features or making risky changes to core functionality. drivers/usb/host/xhci-ring.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 19978f02bb9e..f6ecb3b9fb14 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1313,12 +1313,15 @@ static void xhci_kill_endpoint_urbs(struct xhci_hcd *xhci, */ void xhci_hc_died(struct xhci_hcd *xhci) { + bool notify; int i, j; if (xhci->xhc_state & XHCI_STATE_DYING) return; - xhci_err(xhci, "xHCI host controller not responding, assume dead\n"); + notify = !(xhci->xhc_state & XHCI_STATE_REMOVING); + if (notify) + xhci_err(xhci, "xHCI host controller not responding, assume dead\n"); xhci->xhc_state |= XHCI_STATE_DYING; xhci_cleanup_command_queue(xhci); @@ -1332,7 +1335,7 @@ void xhci_hc_died(struct xhci_hcd *xhci) } /* inform usb core hc died if PCI remove isn't already handling it */ - if (!(xhci->xhc_state & XHCI_STATE_REMOVING)) + if (notify) usb_hc_died(xhci_to_hcd(xhci)); } -- 2.39.5