From patchwork Tue Sep 10 11:13:34 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Pecio X-Patchwork-Id: 827308 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0EF2B1F956 for ; Tue, 10 Sep 2024 11:13:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725966821; cv=none; b=sIykr5EVcGlHzN6kJ5MyVKMJQfh0lGBMbseO5e7blcs/kTdgpp7XU2eiBWIdG4a2iiWr7MdVW2ys3dC34lxyaslPgDOjq2boqstKcfMW9pzSsb+CMjY1oPT7OGr0cFEwx5kDzTPQUS6yooGYUOX8Tjd0EwigrNl8gXlw1+sqwYw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725966821; c=relaxed/simple; bh=CpDE9lfGOcA7ZgEmbg0vjc20zxbs5UXX7H2boJUJ/jo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FkpfFxIxJJS2XIQI04CSb38or/pnVV2tpVIIHZ/H+gL87gg6MpOYyimXIqhXdq3DOBzswQRRmTefIzP3y4sN7+sGH714tlg6crTB9zKnVHJJPw7CCZKED9mITmwuseX6C9nv35DvHnqhqO1NiHaKN9E0hDslJmDfawC4bIp265U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=mr3U9Y3r; arc=none smtp.client-ip=209.85.218.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="mr3U9Y3r" Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a8d13b83511so418657166b.2 for ; Tue, 10 Sep 2024 04:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725966818; x=1726571618; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=B/Y0VfG/93qzYbPDOPjttEMIeKEjz982IJT79fbgsw0=; b=mr3U9Y3rScML8bvySG/N11XOMnzdb2xw4qTRsLaOISO7x+gRiSk34tgb563lZhOHX6 izAPQk/JZGAc5XMpRokz7jHjv/b4JOSzSpGqGkAYXbDphOGziLwfHrh8ODKq6pECqQ7u 4we4k+9wlM1YDK3cDw85Maf76KcRCngIzc+7pHLjRfgwzE0k4za10BqBdoXb28gkC12P REqiX876QuL9Kos/LR/tWtO2REwDZetR9UaTcHL+MrARMnPK1CUltHuqLDyWkZMe2+hS pPW8/LueLqWWeN3w4A4NpcRktwJjacACIhFrMmRxoqmHinmcGGLOT1xy1F/rr9AH0woo kscg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725966818; x=1726571618; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=B/Y0VfG/93qzYbPDOPjttEMIeKEjz982IJT79fbgsw0=; b=Gq4y6jl5jNp1XtnPuglQB6rNeKai5dBNnwbqqG0afhgrR2dPysJv42La0JtnYUMdK/ EF+gPpEwD+wxVyoFeUQxuZwxlEIG1PsW8X0x9CXNypZu56hZvmoljEB6wRJLf+BCfWsF bpGTSejXHdJl0Pmdw7/Uk4Z3k9Oh7U/KF+nEq8L5XlEEHI5veWSPIsCejSI9GAAvv0kt 87w7K1GgFdoa5eJFUeZRwWfcS4YPl6hC8XioqtV1vMYQVwEGFDRTNrEsADgIoU4QoHCu AyhVW7BGDl70zDZ/ld2DD9YHUpWmH6rS8D+NiWq0vJYd8itAbbBlQPgPymV/yxCnLDS5 e+DA== X-Gm-Message-State: AOJu0YzKBJ4CRS/YPE1nD4LCQ39l52CvMc5RoIdc/q8GA/4xTo/FonYb uFsTA8ftxSL0MWzZJcnE6oF/eixoZL77OG6ZdxLRtRhtkRpjxw99 X-Google-Smtp-Source: AGHT+IETPQo4BJSihNKsc9JYHtg1ZTis8j078V7HoDFc29UQvOKhdP3BS2Lcjr7NAJlQ5bXvlKCbPg== X-Received: by 2002:a17:907:3f87:b0:a8d:3998:2de with SMTP id a640c23a62f3a-a8ffaaace71mr38787566b.12.1725966818139; Tue, 10 Sep 2024 04:13:38 -0700 (PDT) Received: from foxbook (bgv123.neoplus.adsl.tpnet.pl. [83.28.85.123]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8d25ced18csm463925066b.161.2024.09.10.04.13.37 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 10 Sep 2024 04:13:37 -0700 (PDT) Date: Tue, 10 Sep 2024 13:13:34 +0200 From: Michal Pecio To: Mathias Nyman , Niklas Neronin Cc: linux-usb@vger.kernel.org Subject: [PATCH 1/5] usb: xhci: Fix handling errors mid TD followed by other errors Message-ID: <20240910131334.5da837f8@foxbook> In-Reply-To: <20240910131233.409c6481@foxbook> References: <20240910131233.409c6481@foxbook> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Some host controllers fail to produce the final completion event on an isochronous TD which experienced an error mid TD. We deal with it by flagging such TDs and checking if the next event points at the flagged TD or at the next one, and giving back the flagged TD if the latter. This is not enough, because the next TD may be missed by the xHC. Or there may be no next TD but a ring underrun. We also need to get such TD quickly out of the way, or errors on later TDs may be handled wrong. If the next TD experiences a Missed Service Error, we will set the skip flag on the endpoint and then attempt skipping TDs when yet another event arrives. In such scenario, we ought to report the 'erorr mid TD' transfer as such rather than skip it. Another problem case are Stopped events. If we see one after an error mid TD, we naively assume that it's a Force Stopped Event because it doesn't match the pending TD, but in reality it might be an ordinary Stopped event for the next TD, which we fail to recognize and handle. Fix this by moving error mid TD handling before the whole TD skipping loop. Remove unnecessary conditions, always give back the TD if the new event points to any TRB outside it or if the pointer is NULL, as may be the case in Ring Underrun and Overrun events on 1st gen hardware. Only if the pending TD isn't flagged, consider other actions like skipping. As a side effect of reordering with skip and FSE cases, error mid TD is reordered with last_td_was_short check. This is harmless, because the two cases are mutually exclusive - only one can happen in any given run of handle_tx_event(). Tested on the NEC host and a USB camera with flaky cable. Dynamic debug confirmed that Transaction Errors are sometimes seen, sometimes mid-TD, sometimes followed by Missed Service. In such cases, they were finished properly before skipping began. Signed-off-by: Michal Pecio --- drivers/usb/host/xhci-ring.c | 70 +++++++++++++++++------------------- 1 file changed, 32 insertions(+), 38 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 4ea2c3e072a9..0cab482b3f4e 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2764,6 +2764,30 @@ static int handle_tx_event(struct xhci_hcd *xhci, return 0; } + /* + * xhci 4.10.2 states isoc endpoints should continue + * processing the next TD if there was an error mid TD. + * So host like NEC don't generate an event for the last + * isoc TRB even if the IOC flag is set. + * xhci 4.9.1 states that if there are errors in mult-TRB + * TDs xHC should generate an error for that TRB, and if xHC + * proceeds to the next TD it should genete an event for + * any TRB with IOC flag on the way. Other host follow this. + * + * We wait for the final IOC event, but if we get an event + * anywhere outside this TD, just give it back already. + */ + td = list_first_entry_or_null(&ep_ring->td_list, + struct xhci_td, td_list); + + if (td && td->error_mid_td && !trb_in_td(xhci, td, ep_trb_dma, false)) { + xhci_dbg(xhci, "Missing TD completion event after mid TD error\n"); + ep_ring->dequeue = td->last_trb; + ep_ring->deq_seg = td->last_trb_seg; + inc_deq(xhci, ep_ring); + xhci_td_cleanup(xhci, td, ep_ring, td->status); + } + do { /* This TRB should be in the TD at the head of this ring's * TD list. @@ -2828,44 +2852,14 @@ static int handle_tx_event(struct xhci_hcd *xhci, return 0; } - /* - * xhci 4.10.2 states isoc endpoints should continue - * processing the next TD if there was an error mid TD. - * So host like NEC don't generate an event for the last - * isoc TRB even if the IOC flag is set. - * xhci 4.9.1 states that if there are errors in mult-TRB - * TDs xHC should generate an error for that TRB, and if xHC - * proceeds to the next TD it should genete an event for - * any TRB with IOC flag on the way. Other host follow this. - * So this event might be for the next TD. - */ - if (td->error_mid_td && - !list_is_last(&td->td_list, &ep_ring->td_list)) { - struct xhci_td *td_next = list_next_entry(td, td_list); - - ep_seg = trb_in_td(xhci, td_next, ep_trb_dma, false); - if (ep_seg) { - /* give back previous TD, start handling new */ - xhci_dbg(xhci, "Missing TD completion event after mid TD error\n"); - ep_ring->dequeue = td->last_trb; - ep_ring->deq_seg = td->last_trb_seg; - inc_deq(xhci, ep_ring); - xhci_td_cleanup(xhci, td, ep_ring, td->status); - td = td_next; - } - } - - if (!ep_seg) { - /* HC is busted, give up! */ - xhci_err(xhci, - "ERROR Transfer event TRB DMA ptr not " - "part of current TD ep_index %d " - "comp_code %u\n", ep_index, - trb_comp_code); - trb_in_td(xhci, td, ep_trb_dma, true); - - return -ESHUTDOWN; - } + /* HC is busted, give up! */ + xhci_err(xhci, + "ERROR Transfer event TRB DMA ptr not " + "part of current TD ep_index %d " + "comp_code %u\n", ep_index, + trb_comp_code); + trb_in_td(xhci, td, ep_trb_dma, true); + return -ESHUTDOWN; } if (ep->skip) { From patchwork Tue Sep 10 11:15:17 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Pecio X-Patchwork-Id: 827307 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 77E9C1862B3 for ; Tue, 10 Sep 2024 11:15:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725966924; cv=none; b=p8sMB703u8PEwu5Qd7ZChlmtOEhHLuh0ppAdzG8NI6iI7DzKvlQYm19VQdPoqfmkbWFOgZbOYDp7rCAFN0gkZw3HuBKORDzb2DPW+b1vxwuDWUp6+2+vJ1fAZMdI+x10P08oLmNzZEc6NZDazEBNFdZTQPPW5XmzbGibGJCz5TU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725966924; c=relaxed/simple; bh=hVmQaTKIEnC6MB1zf/naZVpx7ELe/9fGYtK2/R53pR0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=hQjAGyy1OPTusCYEUyIMC15syPARGNDCA3+Bb091HfOP68D6GEuEePb68XjlQ0NiH49fmwEU7EE+YGCML6D3nOwh1aKSLXi+MmnPN5vgH7rIDeuGLIxyqWw4BWO7R6fhmY8thmxNB/lFNghQiJIjBn9gEQduD/HyZZM1vK6AtOw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YcCg5L+i; arc=none smtp.client-ip=209.85.218.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YcCg5L+i" Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a8d2b4a5bf1so86140266b.2 for ; Tue, 10 Sep 2024 04:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725966921; x=1726571721; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=/yLxqMhD0synWgyzLhpvt1FtY/fRTgGMWh9h9uRXwIU=; b=YcCg5L+iddp4x/VUvrSY56ztBeDoOG6TxvGXHcvRpyiaRn/nJZNUwx2odYzikC870p 7r4rW2mYnzk+z0+f6SuZORA9b9nY5T5puxbatMn8fU/m9FChnxzWahw5ku4KBf8sJZkA qtTMalEdbUMGtONrLELner/D2Tifl6FaVbosMAa0MSpQ1Oft5DmeakDFtVkdjmnn5h9Q N/vjelBppnlo/dNvT2EIkSKUuG2KzO3NnvJNMNPTRvnSNZOZUCRX9gTyT0EgblJjhUTz 79jnUgSjkD5wo6016E4kwcnt83DSpiwE0a5yQSOIJacJt25h2XXKShnizvueFz0TzGS3 UMMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725966921; x=1726571721; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/yLxqMhD0synWgyzLhpvt1FtY/fRTgGMWh9h9uRXwIU=; b=Ttc9xppRiXFXRxiwePJu8xEojyesOjBDL8nsCYYFHoVjNEAcAsm4aFRYFUnLASWJWh ZsSQabDEI72FgICwbui+UzZnDSz8xLvTEdUFR0Q4JjHWEeZi6NdCq+2yZLjVhRwN+zD9 7hyv26r/b1wMCFvPoi8ZT8i7HZJU4p4SUoqhRFCF9moiaRbS3DOaEykZc3XpRBmHeClN Dpag/MXW3XarQbsowMwUZaGcolhopnDVo1um/2KhQdM8NFfEzUZGbqi88OCNvUFS04k4 oVRe/X8MWV+wdhkkhvnVOE2go4fdRmWMmDafPT5uvXkm+o1KK5h9UG4vNd1GtHyFBqac 4Pxw== X-Gm-Message-State: AOJu0Yx0aHEN04gtqQINyPv2sNhqs6/YjcS/77nfoa9YHUQwsAqYhGWC mwRR88NGdZIwr61eXnTX+/0Um2e8DJUI9sWpfXoH1nONaoLw0mL1wU6vnA== X-Google-Smtp-Source: AGHT+IHv3K289g79QfhdrSxc3MmAteHoactj4GG0c45jkD/qQY516DC6zP+KwWW1ZIcowgIvFl2SUw== X-Received: by 2002:a17:907:9813:b0:a86:ac9e:45fd with SMTP id a640c23a62f3a-a8ffae2f33amr38861366b.62.1725966920846; Tue, 10 Sep 2024 04:15:20 -0700 (PDT) Received: from foxbook (bgv123.neoplus.adsl.tpnet.pl. [83.28.85.123]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8d25952761sm467218566b.59.2024.09.10.04.15.19 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 10 Sep 2024 04:15:20 -0700 (PDT) Date: Tue, 10 Sep 2024 13:15:17 +0200 From: Michal Pecio To: Mathias Nyman , Niklas Neronin Cc: linux-usb@vger.kernel.org Subject: [PATCH 3/5] usb: xhci: Unify event handler's 'empty list' and 'no match' cases Message-ID: <20240910131517.2bc8a403@foxbook> In-Reply-To: <20240910131233.409c6481@foxbook> References: <20240910131233.409c6481@foxbook> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Sometimes handle_tx_event() gets an event which doesn't match any pending TD. Or it may be that there are simply no pending TDs at all. These two cases are hardly different, but they are handled by two separate blocks of code. Some logic is pointlessly duplicated, some logic is missing or buggy in one branch or in the other. Reduce the 'empty list' case in the searching loop to a minimum and merge the code removed from there with almost identical code after the loop, which deals with the 'no match' case. This fixes the "spurious success" check in the 'empty list' case not verifying if the host actually has the quirk, and the lack of halted endpoint recovery in the 'no match' case. Remove an obsolete attempt at stall recovery. This code relied on a bug which has been fixed earlier this year, and it was never really fully effective because not all cancelled TDs get No-Op'ed. Make the empty list warning print event completion code, like the 'no match' case does. Signed-off-by: Michal Pecio --- drivers/usb/host/xhci-ring.c | 68 ++++++++++++------------------------ 1 file changed, 23 insertions(+), 45 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 0eef7cd2f20a..56b0c0e85293 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2606,7 +2606,7 @@ static int handle_tx_event(struct xhci_hcd *xhci, int ep_index; struct xhci_td *td = NULL; dma_addr_t ep_trb_dma; - struct xhci_segment *ep_seg; + struct xhci_segment *ep_seg = NULL; union xhci_trb *ep_trb; int status = -EINPROGRESS; struct xhci_ep_ctx *ep_ctx; @@ -2793,28 +2793,12 @@ static int handle_tx_event(struct xhci_hcd *xhci, * TD list. */ if (list_empty(&ep_ring->td_list)) { - /* - * Don't print wanings if it's due to a stopped endpoint - * generating an extra completion event if the device - * was suspended. Or, a event for the last TRB of a - * short TD we already got a short event for. - * The short TD is already removed from the TD list. - */ - - if (!(trb_comp_code == COMP_STOPPED || - trb_comp_code == COMP_STOPPED_LENGTH_INVALID || - ep_ring->last_td_was_short)) { - xhci_warn(xhci, "WARN Event TRB for slot %u ep %d with no TDs queued?\n", - slot_id, ep_index); - } if (ep->skip) { ep->skip = false; xhci_dbg(xhci, "td_list is empty while skip flag set. Clear skip flag for slot %u ep %u.\n", slot_id, ep_index); } - - td = NULL; - goto check_endpoint_halted; + break; } td = list_first_entry(&ep_ring->td_list, struct xhci_td, @@ -2848,11 +2832,8 @@ static int handle_tx_event(struct xhci_hcd *xhci, if (!ep_seg) { /* - * Skip the Force Stopped Event. The 'ep_trb' of FSE is not in the current - * TD pointed by 'ep_ring->dequeue' because that the hardware dequeue - * pointer still at the previous TRB of the current TD. The previous TRB - * maybe a Link TD or the last TRB of the previous TD. The command - * completion handle will take care the rest. + * Ignore the Force Stopped Event. The endpoint may stop on + * some Link or No-Op TRB outside our TDs. We don't care. */ if (trb_comp_code == COMP_STOPPED || trb_comp_code == COMP_STOPPED_LENGTH_INVALID) { @@ -2870,13 +2851,25 @@ static int handle_tx_event(struct xhci_hcd *xhci, } /* HC is busted, give up! */ - xhci_err(xhci, - "ERROR Transfer event TRB DMA ptr not " - "part of current TD ep_index %d " - "comp_code %u\n", ep_index, - trb_comp_code); - trb_in_td(xhci, td, ep_trb_dma, true); - return -ESHUTDOWN; + if (list_empty(&ep_ring->td_list)) { + xhci_warn(xhci, "WARN Event TRB for slot %u ep %d comp_code %u with no TDs queued?\n", + slot_id, ep_index, trb_comp_code); + } else { + xhci_err(xhci, "ERROR Transfer event TRB DMA ptr not part of current TD ep_index %d comp_code %u\n", + ep_index, trb_comp_code); + trb_in_td(xhci, td, ep_trb_dma, true); + } + + /* + * Bugs (in HW or SW) may cause the xHC to execute transfers as + * they are being cancelled and forgotten about. Then we get some + * event and have no idea which transfer caused it. If the event + * indicates that the EP halted, try to fix that at least. + */ + if (xhci_halted_host_endpoint(ep_ctx, trb_comp_code)) + xhci_handle_halted_endpoint(xhci, ep, td, EP_HARD_RESET); + + return 0; } if (trb_comp_code == COMP_SHORT_PACKET) @@ -2887,16 +2880,6 @@ static int handle_tx_event(struct xhci_hcd *xhci, ep_trb = &ep_seg->trbs[(ep_trb_dma - ep_seg->dma) / sizeof(*ep_trb)]; trace_xhci_handle_transfer(ep_ring, (struct xhci_generic_trb *) ep_trb); - /* - * No-op TRB could trigger interrupts in a case where a URB was killed - * and a STALL_ERROR happens right after the endpoint ring stopped. - * Reset the halted endpoint. Otherwise, the endpoint remains stalled - * indefinitely. - */ - - if (trb_is_noop(ep_trb)) - goto check_endpoint_halted; - td->status = status; /* update the urb's actual_length and give back to the core */ @@ -2906,11 +2889,6 @@ static int handle_tx_event(struct xhci_hcd *xhci, process_isoc_td(xhci, ep, ep_ring, td, ep_trb, event); else process_bulk_intr_td(xhci, ep, ep_ring, td, ep_trb, event); - return 0; - -check_endpoint_halted: - if (xhci_halted_host_endpoint(ep_ctx, trb_comp_code)) - xhci_handle_halted_endpoint(xhci, ep, td, EP_HARD_RESET); return 0; From patchwork Tue Sep 10 11:16:51 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Pecio X-Patchwork-Id: 827306 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2802B14D280 for ; Tue, 10 Sep 2024 11:16:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725967018; cv=none; b=paXOtRdfVg62haWiLkpfm68izlYwifBusXMM1/6y9TMzEAw0tLHBgdL9Imlruju0S/YX1HomEn2ZRym4KtcKbE1JfeGHAlz6Z3viqnpqiFijbMqt7OEsaW76sBb8HRH5Nzc/8JvBBdcThxO37DlrH7Cmsd2I5AKS7HEfgyo+fRs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725967018; c=relaxed/simple; bh=RzA8ZfBNebEsL0U5EB0QNzsHYZZILFS9ayPAuMzNedU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=JNOZzVLbQfcmyaNZ/clIixP21ALCI673BDP2w+sY8ts9nGPawfH7e/89OOnEorB+qXKGmo+GVUGPboxpWWhPN9eiY569k1sUUeTI37BhJXrksWxDL7fQq33Sm/dW4ne6Y3bpejr9W5EaLz8sUI/XZRvEknC4QEwSwu6DXBwNMPk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BlcVisH+; arc=none smtp.client-ip=209.85.218.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BlcVisH+" Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a8d2b24b7a8so515618066b.1 for ; Tue, 10 Sep 2024 04:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725967015; x=1726571815; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=NgX0n39MutN0cvoOhVPaaxt+3vWBflrma3+4LJoEaP8=; b=BlcVisH+ZRVtET0jlCK54rDjOWlgE5jDwcbJMqZqOc6KFAN9eHdrxM28uzQ3RoAuQ1 UCc6bVQ56Qy7MXkWSWffycexvHS6EBx/sKQnlwmC4v3TFQjN7KmnILQGk8DPIjSBGhlS fojOQZDYTYmHUw2yba09BTO9sNC+6gNzwaWh/XiPsQhPZY+Uq/4N13JYxB3y13il369V 4yGm+o+HoRWThxy5kQczWRk1gExJFa9nnJ/PrIcKxxjYOGgtPd+KP5k9x/CPclHD4vo8 3N0n/ynH5O38c9HBeQoz7VcWr/veqNZ06OGEYYPLc7gGXC9b3AscJXbfLoKmdg7qOezI y5cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725967015; x=1726571815; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NgX0n39MutN0cvoOhVPaaxt+3vWBflrma3+4LJoEaP8=; b=NseWlMeBGWEcQjCWd0U2oNRv8wqQ7Xka396S/9v2zveJEiCFBD/NG+mRLWfzzizQq3 Ahnh3vVlcZLIFQxydo+pD6GzadZjwbMQHCizFjxS0AHel0p5u+ny0bfMRhbNT8Q6lJYk vZ0vW147FeQtAQTB6cvM+3xGoWQ3Q/yH7Pvmm7mhGk4F+YBb3Vb15yJgX9/C6EScYFGY uNJHUusjcF4/BRWeg6kV20jjCVGPqcoDGh/l/2JSBtx4sA9syq3QKc2qTSTaxxFWAe7q CSHTy7iCV4mmyPTdsAD7cxe6UtC55It8E7A2UX7eRhi+45SeRaux99t2vT1GOiTMe5fP ZJCw== X-Gm-Message-State: AOJu0Yzqlsd7MzTBZQ5grYAf52gNIEJjKwVxmGdWeeVbLv3WAzOEGlJI DJpcrTh3uu1zcueOjVmd61HV2jOgn8Yz5ShwU3KQcIJf0S7YfDgW X-Google-Smtp-Source: AGHT+IHhRZv8aH73spqLvaZpwaWLYgowTlUvPB3ENhkpsThbDaDF6Eti15Lz4Yo/uUuW+cDQi+o6yw== X-Received: by 2002:a17:907:6d09:b0:a7a:8284:c8d6 with SMTP id a640c23a62f3a-a8ffb29987emr38307166b.24.1725967014954; Tue, 10 Sep 2024 04:16:54 -0700 (PDT) Received: from foxbook (bgv123.neoplus.adsl.tpnet.pl. [83.28.85.123]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8d25951020sm468382966b.66.2024.09.10.04.16.54 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 10 Sep 2024 04:16:54 -0700 (PDT) Date: Tue, 10 Sep 2024 13:16:51 +0200 From: Michal Pecio To: Mathias Nyman , Niklas Neronin Cc: linux-usb@vger.kernel.org Subject: [PATCH 5/5] usb: xhci: Fix Ring Underrun/Overrun handling Message-ID: <20240910131651.6c4c0195@foxbook> In-Reply-To: <20240910131233.409c6481@foxbook> References: <20240910131233.409c6481@foxbook> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Depending on implemented spec revision, the TRB pointer of these events may either be NULL or point at enqueue at the time of error occurrence. By the time we handle the event, a new TD may be queued at this address. Ensure that the new TD is not completed prematurely if the event handler is entered due to the skip flag being set on the endpoint. Or, when the TRB pointer is NULL, prevent the empty ring warning being printed. Now that it is safe to enter the event handler, also enter it when the skip flag is not set. This enables completion of any TD stuck in 'error mid TD' state on buggy hosts. Such problem could, for example, happen when a USBFS application knows in advance how many frames it needs and submits the exact number of URBs, then an error occurs on the last TD. One bug remains: when enqueue points at a Link TRB and a new TD appears after that, skipping will remove the new TD prematurely. This should be 255 times less common that the 'matching TD' bug being fixed here, and it will take a major improvement to the skipping loop to fix. Signed-off-by: Michal Pecio --- drivers/usb/host/xhci-ring.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index db9bc7db5aac..475b4d69551b 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2726,14 +2726,10 @@ static int handle_tx_event(struct xhci_hcd *xhci, * Underrun Event for OUT Isoch endpoint. */ xhci_dbg(xhci, "Underrun event on slot %u ep %u\n", slot_id, ep_index); - if (ep->skip) - break; - return 0; + break; case COMP_RING_OVERRUN: xhci_dbg(xhci, "Overrun event on slot %u ep %u\n", slot_id, ep_index); - if (ep->skip) - break; - return 0; + break; case COMP_MISSED_SERVICE_ERROR: /* * When encounter missed service error, one or more isoc tds @@ -2824,6 +2820,15 @@ static int handle_tx_event(struct xhci_hcd *xhci, skipped, td ? "":"not ", slot_id, ep_index); } + /* + * In these events ep_trb_dma is NULL or points at enqueue from the time + * of error occurrence. If it matches a new TD queued since then, don't + * complete the TD now. And otherwise, don't print senseless warnings. + */ + if (trb_comp_code == COMP_RING_UNDERRUN || + trb_comp_code == COMP_RING_OVERRUN) + return 0; + if (!ep_seg) { /*