On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > >>No, the bandwidth wouldn't have been de-allocated until after the > >>callback returned ... and since the callback submitted an urb, > >>it was never de-allocated. (That's the "NYET".) No failure. > > > > You can't do that. The HCD is done with the URB before it makes the > > callback. > > Sure, but the only reason the callback matters (in the pseudocode > of mine that we're talking about) is that when it finishes, the > HCD decides whether the ENDPOINT (not the urb!!) is still busy. > > The HCD is still busy with that endpoint until a while after that > urb callback has completed. If you deallocated the bandwidth while > that endpoint is still busy, of course you'd break things. That's > why that pseudocode didn't do such a thing. :)
Ok, I see your distinction between endpoint and URB. It unfortunately still doesn't work. > >>The second driver is clearly broken, it has no business using > >>the hub interface's endpoint! But I'll assume it's some other > >>thread in the hub driver that decided to do that, so it was > >>a legit attempt to queue a second transfer. > > > > Umm, it doesn't use the hub interface's endpoint. It's just another > > driver that wants to use the bus. > > I couldn't tell that was what you wanted to show, given what you sent > by before. (In fact I scratched my head a while on your ascii art.) > That simplifies things a little bit, but doesn't add an error mode. > > When that second driver submits its urb, assuming that needs > to reserve some bandwidth, the "is it available" logic will be > accounting for the first endpoint's bandwidth consumption. > Because it would never have been released. Yes it will be released. There are no URB's outstanding for that endpoint. Regardless, explaining this race condition to you is moot, because from a conceptual level, your implementation is still not reserving the bandwidth. I'll give you a *completely* seperate example: HID devices. They don't use their interrupt out pipe often, but the bandwidth needs to be reserved so they are never denied it. JE ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
