From: Alan Stern <stern@rowland.harvard.edu> To: Oliver Neukum <oneukum@suse.com> Cc: David Laight <David.Laight@ACULAB.COM>, "gregKH@linuxfoundation.org" <gregKH@linuxfoundation.org>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org> Subject: UAS: fix alignment of scatter/gather segments Date: Mon, 29 Apr 2019 13:55:08 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.1904291346170.1632-100000@iolanthe.rowland.org> (raw) On Mon, 29 Apr 2019, Oliver Neukum wrote: > On Mo, 2019-04-29 at 12:08 -0400, Alan Stern wrote: > > On Mon, 29 Apr 2019, Oliver Neukum wrote: > > > > > On Mo, 2019-04-29 at 15:06 +0000, David Laight wrote: > > > > > But the statement the old comment made are no longer correct. > > > > Perhaps David would be satisfied if the comment were changed to say > > that _some_ USB controller drivers have this unusual alignment > > requirement. > > It would seem to me that every controller that does not do > scatter/gather has this requirement. In other words, this is > the true requirement of USB. It does not come from the > controller. It comes from the protocol's need to not > send a short package. Are you sure that xHCI has this requirement? I haven't checked the spec. I know that UHCI, OHCI, and EHCI do need this alignment (and OHCI and EHCI do in fact have hardware support for scatter-gather). More precisely, what matters is whether the controller is able to merge two different DMA segments into a single packet. UHCI can't. OHCI and EHCI can, but only if the first segment ends at a page boundary and the second begins at a page boundary -- it's easier just to say that the segments have to be maxpacket-aligned. > The second, old, comment is about controllers. Well, if the drivers would use bounce buffers to work around the controllers' issues then they wouldn't have this special requirement. So it really is a combination of what the hardware can do and what the driver can do. Alan Stern
WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern@rowland.harvard.edu> To: Oliver Neukum <oneukum@suse.com> Cc: David Laight <David.Laight@ACULAB.COM>, "gregKH@linuxfoundation.org" <gregKH@linuxfoundation.org>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org> Subject: Re: [PATCH] UAS: fix alignment of scatter/gather segments Date: Mon, 29 Apr 2019 13:55:08 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.1904291346170.1632-100000@iolanthe.rowland.org> (raw) Message-ID: <20190429175508.3GUXqtEFXBaL3RRGe7NeHaZD8AKKioWhuLdRr6I4RSM@z> (raw) In-Reply-To: <1556557130.20085.24.camel@suse.com> On Mon, 29 Apr 2019, Oliver Neukum wrote: > On Mo, 2019-04-29 at 12:08 -0400, Alan Stern wrote: > > On Mon, 29 Apr 2019, Oliver Neukum wrote: > > > > > On Mo, 2019-04-29 at 15:06 +0000, David Laight wrote: > > > > > But the statement the old comment made are no longer correct. > > > > Perhaps David would be satisfied if the comment were changed to say > > that _some_ USB controller drivers have this unusual alignment > > requirement. > > It would seem to me that every controller that does not do > scatter/gather has this requirement. In other words, this is > the true requirement of USB. It does not come from the > controller. It comes from the protocol's need to not > send a short package. Are you sure that xHCI has this requirement? I haven't checked the spec. I know that UHCI, OHCI, and EHCI do need this alignment (and OHCI and EHCI do in fact have hardware support for scatter-gather). More precisely, what matters is whether the controller is able to merge two different DMA segments into a single packet. UHCI can't. OHCI and EHCI can, but only if the first segment ends at a page boundary and the second begins at a page boundary -- it's easier just to say that the segments have to be maxpacket-aligned. > The second, old, comment is about controllers. Well, if the drivers would use bounce buffers to work around the controllers' issues then they wouldn't have this special requirement. So it really is a combination of what the hardware can do and what the driver can do. Alan Stern
next reply other threads:[~2019-04-29 17:55 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-29 17:55 Alan Stern [this message] 2019-04-29 17:55 ` [PATCH] UAS: fix alignment of scatter/gather segments Alan Stern -- strict thread matches above, loose matches on Subject: below -- 2019-04-30 14:39 Alan Stern 2019-04-30 14:39 ` [PATCH] " Alan Stern 2019-04-30 9:16 David Laight 2019-04-30 9:16 ` [PATCH] " David Laight 2019-04-29 19:42 Alan Stern 2019-04-29 19:42 ` [PATCH] " Alan Stern 2019-04-29 18:42 Oliver Neukum 2019-04-29 18:42 ` [PATCH] " Oliver Neukum 2019-04-29 16:58 Oliver Neukum 2019-04-29 16:58 ` [PATCH] " Oliver Neukum 2019-04-29 16:08 Alan Stern 2019-04-29 16:08 ` [PATCH] " Alan Stern 2019-04-29 15:57 Oliver Neukum 2019-04-29 15:57 ` [PATCH] " Oliver Neukum 2019-04-29 15:06 David Laight 2019-04-29 15:06 ` [PATCH] " David Laight 2019-04-29 14:32 Oliver Neukum 2019-04-29 14:32 ` [PATCH] " Oliver Neukum 2019-04-29 14:19 David Laight 2019-04-29 14:19 ` [PATCH] " David Laight 2019-04-29 13:38 Oliver Neukum 2019-04-29 13:38 ` [PATCH] " Oliver Neukum 2019-04-29 13:31 David Laight 2019-04-29 13:31 ` [PATCH] " David Laight 2019-04-29 12:20 Oliver Neukum 2019-04-29 12:20 ` [PATCH] " Oliver Neukum
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=Pine.LNX.4.44L0.1904291346170.1632-100000@iolanthe.rowland.org \ --to=stern@rowland.harvard.edu \ --cc=David.Laight@ACULAB.COM \ --cc=gregKH@linuxfoundation.org \ --cc=linux-usb@vger.kernel.org \ --cc=oneukum@suse.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.