Alan Stern wrote:
Is there any reason why the status couldn't be changed if the low-level HC
driver detects that the hardware did manage to complete the transfer
before it could be dequeued? When that happens, why not report that the
URB succeeded and the unlink failed -- which is what really
This really makes no sense to me. There's a field, with
an SMP-safe lock. The protocol between one layer and
the next involves holding that lock before changing that
field. And you're saying that's racey. How?
It seems to me that you are racing against HC hardware.
You cannot unlink an
On Fri, 18 Jul 2003, Oliver Neukum wrote:
It seems to me that you are racing against HC hardware.
Yes, certainly.
You cannot unlink an URB that is being executed, can you?
With UHCI you can. What will happen is that the HCD will finish executing
the current TD, but on its next loop through
On Thu, 17 Jul 2003, Pete Zaitcev wrote:
Date: Thu, 17 Jul 2003 23:01:42 -0400 (EDT)
From: Alan Stern [EMAIL PROTECTED]
[...] But a properly-written driver won't
touch the URB _at all_ once it has been submitted until the completion
callback.
I said the same. It cannot look at the
Alan Stern wrote:
On Fri, 18 Jul 2003, Oliver Neukum wrote:
It seems to me that you are racing against HC hardware.
Yes, certainly.
But not at that level, and URBs aren't hardware
data structures either.
You cannot unlink an URB that is being executed, can you?
With UHCI you can. What will
David:
I think you misunderstood some of what I wrote (and I'm probably
misunderstanding some of what you wrote too). A large part of the problem
seems to be that Oliver and I used unlink to mean remove from the
hardware schedule before the hardware is through with it -- maybe you say
dequeue to
Alan Stern wrote:
David:
I think you misunderstood some of what I wrote (and I'm probably
misunderstanding some of what you wrote too). A large part of the problem
seems to be that Oliver and I used unlink to mean remove from the
hardware schedule before the hardware is through with it -- maybe
I'll make this short, since most of the issues in this thread involve
questions originally asked by Oliver that by now have been answered.
I'm not aware of any drivers that check to see whether a call to
usb_unlink_urb() failed because the URB had already completed. That makes
all this pretty
Johannes:
A bug has turned up in the UHCI driver. Briefly, when an URB completes,
uhci_transfer_result() doesn't store the status in urb-status but only in
urbp-status. urb-status is set just before calling hcd_giveback_urb().
However, the hcd glue layer uses urb-status == -EINPROGRESS as a
Am Donnerstag, 17. Juli 2003 23:09 schrieb Alan Stern:
Johannes:
A bug has turned up in the UHCI driver. Briefly, when an URB completes,
uhci_transfer_result() doesn't store the status in urb-status but only in
urbp-status. urb-status is set just before calling hcd_giveback_urb().
Oliver Neukum wrote:
Am Donnerstag, 17. Juli 2003 23:09 schrieb Alan Stern:
Johannes:
A bug has turned up in the UHCI driver. Briefly, when an URB completes,
uhci_transfer_result() doesn't store the status in urb-status but only in
urbp-status. urb-status is set just before calling
Am Freitag, 18. Juli 2003 00:38 schrieb David Brownell:
Oliver Neukum wrote:
Am Donnerstag, 17. Juli 2003 23:09 schrieb Alan Stern:
Johannes:
A bug has turned up in the UHCI driver. Briefly, when an URB completes,
uhci_transfer_result() doesn't store the status in urb-status but only
From: David Brownell [EMAIL PROTECTED]
Date: Thu, 17 Jul 2003 15:38:11 -0700
A bug has turned up in the UHCI driver. Briefly, when an URB completes,
uhci_transfer_result() doesn't store the status in urb-status but only in
urbp-status. urb-status is set just before calling
However, the hcd glue layer uses urb-status == -EINPROGRESS as a test for
It shouldn't use it. The clean way to fix this issue is to have an explicit
state field.
But urb-status ** IS ** an explicit state field.
It holds the first fault experienced by that request. One of
those fault codes is a
Date: Thu, 17 Jul 2003 18:39:38 -0700
From: David Brownell [EMAIL PROTECTED]
So the completion uses an extra field to indicate that
urb was released by HC driver to the uppper level.
It's not an explicit field, it's an extra field.
This really makes no sense to me. There's a field,
On Thu, 17 Jul 2003, David Brownell wrote:
Oliver responded:
Right, it holds information about the status of the io operation the URB
describes. It doesn't hold information about the status of the URB itself,
such as unlinkable, ununlinkable, running completion handler, unlinked
These
On Thu, 17 Jul 2003, Pete Zaitcev wrote:
The urb-lock is situated in the same chunk of storage
as the urb-status, so it only can protect the status if
there is no hazard of deallocation of the urb. However, our
API makes no such guarantees across the call to the -complete.
Therefore,
Date: Thu, 17 Jul 2003 23:01:42 -0400 (EDT)
From: Alan Stern [EMAIL PROTECTED]
[...] But a properly-written driver won't
touch the URB _at all_ once it has been submitted until the completion
callback.
I said the same. It cannot look at the urb-status.
-- Pete
Pete Zaitcev wrote:
Date: Thu, 17 Jul 2003 18:39:38 -0700
From: David Brownell [EMAIL PROTECTED]
So the completion uses an extra field to indicate that
urb was released by HC driver to the uppper level.
It's not an explicit field, it's an extra field.
This really makes no sense to me. There's a
19 matches
Mail list logo
