From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 163EEC31E46 for ; Wed, 12 Jun 2019 14:44:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EB987206BB for ; Wed, 12 Jun 2019 14:44:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729256AbfFLOoK (ORCPT ); Wed, 12 Jun 2019 10:44:10 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:55690 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S2439871AbfFLOnM (ORCPT ); Wed, 12 Jun 2019 10:43:12 -0400 Received: (qmail 3203 invoked by uid 2102); 12 Jun 2019 10:43:11 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 12 Jun 2019 10:43:11 -0400 Date: Wed, 12 Jun 2019 10:43:11 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Christoph Hellwig cc: Oliver Neukum , "iommu@lists.linux-foundation.org" , Yoshihiro Shimoda , "linux-block@vger.kernel.org" , Linux-Renesas , "linux-usb@vger.kernel.org" Subject: Re: How to resolve an issue in swiotlb environment? In-Reply-To: <20190612120653.GA25285@lst.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Wed, 12 Jun 2019, Christoph Hellwig wrote: > On Wed, Jun 12, 2019 at 01:46:06PM +0200, Oliver Neukum wrote: > > > Thay is someething the virt_boundary prevents. But could still give > > > you something like: > > > > > > 1536 4096 4096 1024 > > > > > > or > > > 1536 16384 8192 4096 16384 512 > > > > That would kill the driver, if maxpacket were 1024. > > > > USB has really two kinds of requirements > > > > 1. What comes from the protocol > > 2. What comes from the HCD > > > > The protocol wants just multiples of maxpacket. XHCI can satisfy > > that in arbitrary scatter/gather. Other HCs cannot. > > We have no real way to enforce that for the other HCs unfortunately. > I can't really think of any better way to handle their limitations > except for setting max_segments to 1 or bounce buffering. Would it be okay to rely on the assumption that USB block devices never have block size < 512? (We could even add code to the driver to enforce this, although refusing to handle such devices at all might be worse than getting an occasional error.) As I mentioned before, the only HCD that sometimes ends up with maxpacket = 1024 but is unable to do full SG is vhci-hcd, and that one shouldn't be too hard to fix. Alan Stern