qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] hw/usb-ohci: Honour endpoint maximum packet


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 1/2] hw/usb-ohci: Honour endpoint maximum packet size
Date: Thu, 15 Sep 2011 11:08:14 +0100

On 15 September 2011 10:13, Gerd Hoffmann <address@hidden> wrote:
> On 09/15/11 10:36, Peter Maydell wrote:
>>
>> On 15 September 2011 08:33, Gerd Hoffmann<address@hidden>  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.

The OHCI spec still requires us to only process one max-packet-size
worth of data from this TransferDescriptor before we move on to
the next one, though, doesn't it? (cf the flowchart in fig 6-7).
It seems to me that at least some of that is likely to be
guest-visible, especially in the case where an endpoint returns an
error partway through. So it's not clear to me that you could
validly batch up everything in the TD and do it all at once.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]