From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R480d-0003W9-1j for qemu-devel@nongnu.org; Thu, 15 Sep 2011 05:13:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R480c-00020B-0c for qemu-devel@nongnu.org; Thu, 15 Sep 2011 05:13:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R480b-000206-NP for qemu-devel@nongnu.org; Thu, 15 Sep 2011 05:13:25 -0400 Message-ID: <4E71C1B0.5070607@redhat.com> Date: Thu, 15 Sep 2011 11:13:20 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1316022540-31355-1-git-send-email-peter.maydell@linaro.org> <1316022540-31355-2-git-send-email-peter.maydell@linaro.org> <4E71AA5D.2070400@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] hw/usb-ohci: Honour endpoint maximum packet size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org, patches@linaro.org On 09/15/11 10:36, Peter Maydell wrote: > On 15 September 2011 08:33, Gerd Hoffmann wrote: >> On 09/14/11 19:48, Peter Maydell wrote: >>> >>> Honour the maximum packet size for endpoints; this applies when >>> sending non-isochronous data and means we transfer only as >>> much as the endpoint allows, leaving the transfer descriptor >>> on the list for another go next time around. This allows >>> usb-net to work when connected to an OHCI controller model. >> >> Hmm, I'd tend to fix it the other way around: Fix usb-net to deal with >> transfers larger than the endpoint packet size. What do you think? > > Honouring maximum packet size is mandated by the OHCI spec: > see section 4.3.1.3.2 "Packet Size" in OHCI specification 1.0a. > Our failure to do it is just a bug in our controller model. No. What I think is that USBPacket shouldn't be required to be an actual USB packet, but a transfer, i.e. do the splitting of larger transfers into smaller packets in the usb driver emulation (if needed), not the host adapter emulation. Maybe it is a good idea to rename USBPacket to USBTransfer to make that clear. > If you want to make our usb-net implementation permit and > advertise a larger max-packet-size (and test it for > interoperability with a pile of OSes :-)) that's a different > thing. Also add usb 2.0 support while being at it. But that is another story ... cheers, Gerd