Hi Matt,

> (1) I've never been able to get a consistent answer on short/zero-length
> packet terminating a series of URBs that use QUEUE_BULK.  If I could get a
> _guarantee_ that it works as you advertise, I'd be much happier.  But this
> has been the least-well supported feature of the HCDs, and I've been
> reluctant to try it.  2.5 should reduce that reluctance, but I'm still
> skeptical.

Actually, I've not heard the question, and didn't notice myself talking
about that particular issue.  Could you elaborate?  I'm still not fully
trusting that all the HCDs implement bulk queuing consistently, and
I've already mentioned fault handling there as one issue.  (Wouldn't
get any better with a s/g operations in usbcore, since it's an issue of
consistency of implementation:  the same kind of attention is needed
to resolve the problem, no matter where it resides.)


> (2) What about the race condition between submitting URBs with QUEUE_BULK
> and having one of them terminate?  That is, what if we're doing a read and
> the first URB gets terminated with a short-packet _before_ we submit the
> 2nd URB of the data sequence?

That's one of those "should not happen" cases that's got the feeling of
something that will actually show up in some cases ... :)

>      Will the 2nd URB get retired because the HCD
> recognizes this based on the QUEUE_BULK flag?  Or does the status end up in
> the userspace buffer?  

I think the right model, outside of whatever layer this is, clearly is
that submitting the set of URBs (and getting back clean status)
is an atomic action.  There are a lot of ways to achieve that.

I think it ought to be doable without API changes to usbcore.
It's sort of like the submit-time analogue of the unlink races
that crop up when drivers unlink URBs as HCDs are firing
completion handlers.  It'll need some attention, but it's a fixable
problem.

>        Can the driver tell the difference then between this
> case and a very slow device stuck in it's data-transfer phase?

I don't follow this question at all -- are you assuming that the
set of queueable URBs isn't submitted atomically?

- Dave



_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to