From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (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 09DBD2DC774 for ; Wed, 19 Nov 2025 11:02:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763550136; cv=none; b=avxR5O3wkTTkINQy2eg3IKZw1FExhvANyixebkTxS+yAjNTihCmvgNtSMh2znwHgQonyuynOJvw2cSulbbR0vVU0qG2CTiDOdiFEUzPtIENDStcneqW0hTyCI9UaBhG5FRKWD1DydiNIa4V0HmJGaaHJmB15vvBSVnqSh/IcqBE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763550136; c=relaxed/simple; bh=fvmZiiuC9jCtgaL8qw/5yNya6Ce+iiqP2FKgu7P/vIY=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=AT12OkxZ0IJibXZ7UCG8wKGNfRM7TwG8B3dTnJKoVoFsTGbWR769T0CZWw7YWQglz/hrKkfOGbCOIjzp9s0opkSnR3ECLi2l1wE6t3xTkO1E5ewxP5zQTKIZk86eogXUJk81mvN4d4RtHsDBGbg/npxJIGG4VkIWiVehhDfhUjw= 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=X3gHq9BP; arc=none smtp.client-ip=209.85.208.45 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="X3gHq9BP" Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-640a3317b89so9854447a12.0 for ; Wed, 19 Nov 2025 03:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763550133; x=1764154933; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:subject:cc:to :from:date:from:to:cc:subject:date:message-id:reply-to; bh=K+jLnN1hAUVFGAduW9V62lyAXS4wcslys/Va1Bxsbb0=; b=X3gHq9BPSd28dcm2PRYR0Xje2jXSqLHMLsjFmLSzrdJo7PX0pzxmOiaqKEZdm3FCTV LfKuOhmpxqrluSsttvDhi+KqfleG4aZvTmEccFaucC/YkA/KHYhAotUNO22nsrEP8XG+ DgDRbRdhFBnkxf+F13WEY90e1o9fkE3YaY6blTh5RxuZA+Q/yBtzLwT6KXd25sCrD9/V I4dM6NcOQb4/w23tF+dfNbMXX6qoZDeUpMg0RZRNW5p5w9gqOWfSKHbCRr3hwDr9vwDw Pi9gZT+9Z8m3tLvbjrzbVHVHCesiuSnlzf1Ti2rbhHHrbhPHIZZGOWxe6iOiEYIREoqe GnQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763550133; x=1764154933; h=content-transfer-encoding:mime-version:message-id:subject:cc:to :from:date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=K+jLnN1hAUVFGAduW9V62lyAXS4wcslys/Va1Bxsbb0=; b=MEbHzR6yMvnIahd0JgPaBzAdmGgdbe5mLZd+/CymBgGWFU/QZofaAAb8Jv3cYmzO0W IjQaPmAGScCcnCFPC05tu34/3DF99tY5qEwdTkJefF9LwDF+uZpGp2/rq8gt5CYmn9Lb ngGp2bdx4epW3f7IPFxAHElfQVurQdAX8/GuWjoNhftdCh3m01X8JE1d+hAgQsQQMoya tZRULiyu/y7CWKcdYhkNm6M6GzEBCijoFRGR3uCmO/TTBaIjfCaK7tqq/AJXomW+ISjQ 67qwO47dXgsJ+4/nssLm6w64eKVZzbk/bv+BmqMiYgLWqeaMikljznHQGOr59/PaZvH9 16YA== X-Forwarded-Encrypted: i=1; AJvYcCUnmbRGZTWqJZGQJGoJ1PqLlfNl4kF9Xzzcdsip2ktG583eWq0tOJtB4cCq0F6gT7A0smZY0dsOBfIzy5A=@vger.kernel.org X-Gm-Message-State: AOJu0YyXLcqtktgQU2QBf1mXtYD/TPwle3YrIMMkDcuQH5/r9b/BAbOc 5bbRJNvxN6BYvBMLLoKCs91hSyzaf4pHrEigznbv0S+Jmu2HlSha5Qt6 X-Gm-Gg: ASbGncs8heyohwCOK/YdadatV+bEIJ5JI4ppFTvwkHKITUPLPRp1hbtBKQQqkU7M4au 4NBkcsT3Xd6l0A27V1sg+f7WZe8PSNFTZgoLHU6riM3kZErEDKS5UPLJFj8f7ypKg+65n5ORCIR 3UDdhHp9Abeew8ujA5+aKTm/11HnVDPvlsrKrDkRnvOq+xndIchyPbrcnNYDXIGPEXUzj6wK59N FMt7ZrSb08adXqoEWVlTETDcuz2LPaicvtwUmYRaRKSwuR404U06tKe2b3mi5+GbaKpBW2uadH/ Y3Mubxzb0jXujbbuFfOsbrd0wYTYBa86EOVnOw4nqW26psXBpeNPjpku13EsK1H3IKYY/0GmZhu VvysFnENBcRSBcQOoh+gAp96ll2D3UpH9vvnUV2Km2JKXhCagMPb5wYNpxTWZWN5pAAhelLRi6k 1w8agFZV4lwf9SS5uCrw4LtoYcXSJcvf25uA== X-Google-Smtp-Source: AGHT+IG1afES/XV2bo4MB7VzzF+Ue9Ifqe7vhIWAKzFI37FLf/iR5dK2plv5L3tJ2TcBJbQi4ks7Aw== X-Received: by 2002:a05:6402:2806:b0:643:5f45:6fa5 with SMTP id 4fb4d7f45d1cf-6435f457518mr16163433a12.33.1763550132952; Wed, 19 Nov 2025 03:02:12 -0800 (PST) Received: from foxbook (bhd138.neoplus.adsl.tpnet.pl. [83.28.93.138]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6450857c5c1sm3228143a12.27.2025.11.19.03.02.12 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 19 Nov 2025 03:02:12 -0800 (PST) Date: Wed, 19 Nov 2025 12:02:08 +0100 From: Michal Pecio To: Mathias Nyman , Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/5] xHCI: Decouple updating Dequeue from giveback Message-ID: <20251119120208.6a025eb0.michal.pecio@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, This introduces unified mechanism for handling all short transfers and errors mid TD plus their later events, accurately and in-spec. I have been working on this code on and off for the last few months, it's dead simple conceptually and tested a lot on various hardware. When a TD completes early, store its end_trb on ep_ring and give it back. Use end_trb to recognize future events for the TD. Remove the SPURIOUS_SUCCESS quirk and unreliable comp code guesswork. Isochronous TDs with errors are given back instantly, which reduces latency and eliminates the need for error_mid_td flag and some hacks like handling Missed Service only to give back error_mid_td. Dequeue will be moved in accordance with received events, never to the next TD right away. Previous code would do that on Short Packet, allowing overwriting of remaining TRBs if it happens across segment boundary. Rare enough that no one complained, but obviously wrong. We will need a trb_in_range(), and I used this as an opportunity to smuggle some long-discussed changes and improve trb_in_td() usage. After converting from dma_addr_t to trb* once in handle_tx_event(), pass ep_trb instead ep_trb_dma to trb_in_td(). This requires a rewrite of trb_in_td(). New version is easier and shorter. While I'm aware it could be shorter still by using segment numbers, it has two advantages which I thought are neat: * It can detect when "suspect" TRB is on a different ring than TD. This means it has a loop, but common cases never enter it. (And yes, I've seen this warning once, but I suspect corruption - DMA UAF was involved. Things improved with pdev->untrusted = 1). * Needs only one segment pointer (suspect). Call sites are tidier and I don't need to store last TD's end_seg together with end_trb. Alternatively, segment numbers can also be used, but I really wanted to see if the code could be less noisy. Regards, Michal Michal Pecio (5): usb: xhci: Track transfer ring dequeue progress properly usb: xhci: Find transfer TRB early in handle_tx_event() usb: xhci: Refactor and generalize trb_in_td() usb: xhci: Reduce error mid TD latency with a new "done TD" mechanism usb: xhci: Handle short transfers as "done TDs" drivers/usb/host/xhci-mtk.c | 5 - drivers/usb/host/xhci-pci.c | 5 - drivers/usb/host/xhci-ring.c | 318 +++++++++++++++++++---------------- drivers/usb/host/xhci.c | 7 - drivers/usb/host/xhci.h | 5 +- 5 files changed, 174 insertions(+), 166 deletions(-)