On Tue, May 22, 2001 at 01:11:12PM -0700, David Brownell wrote:
> > My hope was that I could use the fact that the ->next pointer doesn't
> > submit the data stage URB until _after_ the command stage URB is completed.
>
> As I say, this is naturally done in the completion sequence,
> outside the HCD (and today, in the completion handler).
> My main issue is that the HCDs shouldn't need to care
> about such stuff: they should deal with I/O transfers, and
> that's about all.
>
> Now, if some shared code, like the usb_hcd_giveback_urb()
> routine used currently by the EHCI driver, were to basically
> usb_submit_urb (urb->next) before it invoked the completion
> handler on a successful urb, I'd be happy enough. (More so
> if all the HCDs did the same kind of stuff...)
This sounds like exactly what I want. Perhaps waiting for shared-code
merging will bring about everything I'd like to see....
> If you're saying you want the first error from a chain of (bulk) requests to
> kill all the other requests in that chain, I'd be happy with that answer ... I've
> had a question in that area! I can make EHCI bulk do that quickly enough;
> dunno what other HCDs do today.
Yes and no. If I have a chain of URBs (via ->next), nothing says they all
have to be for the same endpoint, or even the same device. I'd like them
to be processed as I'd expect -- one submitted after the other, with
"typical" results.
Thus, if I was writing and my bulk out endpoint STALLed, then yes, I want
the string of bulk-out transfers to all fail with -EPIPE. However, if
there is a bulk-in transfer in the chain, why not do it? Better yet, if
there is a CLEAR_HALT in the chain, execute that too, and then everything
after that will be fine.
I don't want much HCD brains here... I just want a bunch of URBs submitted
for me without me having to worry about it much.
> > The device can be removed, which retires all the URBs. Short packets won't
> > happen, and if they do, we're so hosed anyway that killing the device is
> > the only option....
>
> Ah, isn't it desirable to recover from many failures? I guess that's an
> issue in the filesystem/scsi/... layering. Read alternate blocks, write
> to a better sector, and so on. Killing seems too severe.
If the firmware in the device has crashed, killing is the only option.
Most failure modes I've seen come from the firmware dying, or the HCD
locking up. Very rarely do I see an error that is unexpected and
recoverable.
> I'm talking about stuff I don't want to see in HCDs, you're talking about stuff
> you don't want to see in device drivers. Luckily there's software between the
> two, which could handle such stuff!
>
> Suppose you could submit an urb->next chain:
>
> control (for command)
> bulk (block1)
> bulk (block2)
> bulk (block3)
> ...
> bulk (blockN)
> bulk (status)
>
> The engine could presumably hide inside usb_submit_urb, but not
> nessarily need to live inside each HCD ...
Sounds good to me. I'd also like to be able to use completion handlers on
some (but not all) of those URBs. But I could, if I had to, live without
that.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
It was a new hope.
-- Dust Puppy
User Friendly, 12/25/1998
PGP signature
