>>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. :) >>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. > Correction, when it's the *only* URB to that endpoint. You're making the > assumption that an URB will always be submitted. No I wasn't. Notice the "qlen = 0" case ... no urb submitted then. If that happens before the callback, no problem -- bandwidth still reserved. If that happens afterwards, it's safe to free since the driver is no longer using it. - Dave ------------------------------------------------------- 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
