All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Krasnyansky <maxk@kernel.org>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Preliminary patch to implement ehci
Date: Sat, 01 Nov 2008 13:01:42 -0700	[thread overview]
Message-ID: <490CB5A6.8020203@kernel.org> (raw)
In-Reply-To: <490B7095.8030105@kernel.org>

Max Krasnyansky wrote:
> Anthony Liguori wrote:
>> Mark Burkley wrote:
>>> Hi Anthony,
>>>
>>> I have ehci built against trunk now but I am seeing an issue with a
>>> memory key I am using for testing.  ioctl returns EPIPE (which I
>>> would have thought was a STALL) to an asynchronous IN completion in
>>> usb-linux.c but then this is returned as USB_RET_NAK to EHCI which
>>> confuses my WinXP target because the transfer is then never
>>> completed.
>>>
>>> Can I just check that it was intentional to return NAK for EPIPE
>>> returns in asynchronous completions?  If so, then I will try to
>>> detect the stall in my implementation and treat differently to a
>>> NAK.  It's just that if I modify usb-linux.c to return
>>> USB_RET_STALL on -EPIPE then it works fine.
> 
> I just looked at the usb-linuc.c:async_complete() code and it looks like
> it was intentional but I cannot remember why I wrote that way. And what
> you're saying makes sense. ie It should be a STALL. In fact I think that
> might fix the regression with USB storage devices that some people have
> reported.
> I'll play some more with this later today. I want to make sure that the
> change we're talking about does not break existing devices that I
> thoroughly tested as part of the usb async re-write. If everything works
> as expected then we'll change it.

Ok. I just tested that change (ie returning STALL instead of NAK on EPIPE)
with a bunch of devices: USB serial adapter, CF card reader, USB webcam (MS
VX-3000) and MS USB mouse. All that stuff was hooked up to XP-SP3 and all of
them are perfectly usable at the same time.

In other words here is my ACK :)
I'll take a look and play with the EHCI patch later today.

Thanx
Max

  parent reply	other threads:[~2008-11-01 20:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1KqsdV-0000r9-5B@monty-python.gnu.org>
2008-10-17 19:42 ` [Qemu-devel] Preliminary patch to implement ehci Mark Burkley
2008-10-27  8:44   ` Mark Burkley
2008-10-27 14:00     ` Anthony Liguori
2008-10-27 14:27       ` Glauber Costa
2008-10-27 15:26         ` [Qemu-devel] " Jan Kiszka
2008-10-27 15:29       ` [Qemu-devel] " Mark Burkley
2008-10-30 16:43       ` Mark Burkley
2008-10-30 17:17         ` Anthony Liguori
2008-10-31 20:54           ` Max Krasnyansky
2008-11-01 10:49             ` Mark Burkley
2008-11-01 20:01             ` Max Krasnyansky [this message]
2008-11-01 20:50           ` Max Krasnyansky
2008-11-05  9:52             ` Mark Burkley
2009-01-13 17:59               ` René Rebe
2009-03-02  7:16   ` Xin, Xiaohui

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=490CB5A6.8020203@kernel.org \
    --to=maxk@kernel.org \
    --cc=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    /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: link
Be 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.