> > Why -- what's wrong with reusing that device's address as soon > > as it's fully disconnected? > > Because the deallocate() callback doesn't have guarantees that the HC > has to be completely done with any references to the device address.
You wouldn't be about to say that's a feature, not a bug, and that your UHCI code cares about it ... would you? :) > In fact the existing 2.4 is racy that way. We free up the bit for the > device address before we call deallocate() which in usb-ohci atleast > unlinks HC state with the device address (the ED). The EDs are coupled to dev->hcpriv, so there's no ambiguity. What races? Any new device using that address will have a different dev, and different EDs. I'm not sure I see there's a problem there, unless maybe the UHCI drivers are making problematic assumptions. > > If you did that, the dev->bus linkage wouldn't be broken ... so > > those clean failures wouldn't be possible, and the HCDs could > > be in the business of creating new state for disconnected HW! > > That's just because we overload the meaning of dev->bus to mean the > device is valid or not. > > That could be changed. I'd thought about that. All of this gets into those issues of needing to clarify the semantics of this "zombie device" state. Which is one of those issues I pointed out quite some time back ... the 2.5.15 code doesn't have such issues. Is there a compelling reason to choose a complicated way to represent an invalid device? A non-compelling one is that as soon as the hub driver sees a device is gone, it could mark it so any new transactions (during cleanup) fail much earlier. - Dave _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
