From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kw11Q-0003yp-28 for qemu-devel@nongnu.org; Fri, 31 Oct 2008 16:55:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kw11O-0003yd-I6 for qemu-devel@nongnu.org; Fri, 31 Oct 2008 16:55:06 -0400 Received: from [199.232.76.173] (port=45936 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kw11O-0003ya-C1 for qemu-devel@nongnu.org; Fri, 31 Oct 2008 16:55:06 -0400 Received: from hera.kernel.org ([140.211.167.34]:47149) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kw11O-00046e-8L for qemu-devel@nongnu.org; Fri, 31 Oct 2008 16:55:06 -0400 Message-ID: <490B7095.8030105@kernel.org> Date: Fri, 31 Oct 2008 13:54:45 -0700 From: Max Krasnyansky MIME-Version: 1.0 Subject: Re: [Qemu-devel] Preliminary patch to implement ehci References: <11d301c93090$7e06d290$7a1477b0$@com> <010f01c93810$47ccb500$d7661f00$@com> <4905C997.5060801@codemonkey.ws> <01d701c93aae$af7487a0$0e5d96e0$@com> <4909EC32.1090504@codemonkey.ws> In-Reply-To: <4909EC32.1090504@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org 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. btw It's awesome that you're working on EHCI. I was going to work on it right after making the stack fully async but got swamped with other things. Do you have a git tree I could pull your stuff from ? Thanx Max