Am Donnerstag, 8. Januar 2004 16:47 schrieb Alan Stern:
> I'm recombining the different parts of this thread, since things seem to
> be winding down.
>
>
> On Wed, 7 Jan 2004, David Brownell wrote:
>
> > Why shouldn't it be possible for the hub code to sort that stuff
> > directly? Logically it's just setting a flag. Maybe dev->state
> > should be protected by some lock, but certainly it's easy to have
> > a bit that can record the disconnect even if a down_trylock()
> > can't grab that lock. Then dev->state could be updated later
> > when it's more "polite".
>
> This is a key issue: whether usbdev->state needs to be protected by some
> sort of lock. So long as it is only changed by the hub driver no lock is
> required. The problem is that it can be changed by other threads as well
> via usb_set_configuration() and usb_reset_configuration(), maybe other
> routines too. The best approach might be to have these routines _not_
> change usbdev->state but instead ask the hub driver to change it for them.
> That change (which need not take place immediately) could then be
> synchronized with the other actions of the hub driver in some private way.
This would introduce a lot of complexity as such routines can be called
from the hub driver's context and other contexts. Not pretty. Furthermore,
is khubd running during resumption from power save?
> In particular, and most importantly, it would mean that usbdev->serialize
> would _not_ protect usbdev->state, contrary to what I've been assuming all
Quite counterintuitive, which is bad.
> along. This would make it easy to change the state to NOTATTACHED for all
> devices in a subtree as soon as a disconnection is detected. The
> remainder of disconnect processing (unbinding drivers, unregistering
> devices, etc.) could then be handled in another thread with no penalty.
> These changes are sufficiently well localized that they could be
> introduced in 2.6.
>
> As another possible approach, we might want to make USB_STATE_CONFIGURED
> _not_ a state at all. Then usb_set_configuration et al. wouldn't have to
> touch usbdev->state and life would be simpler. The equivalent information
> is available anyhow by way of usbdev->actconfig.
Helping you how?
> > [ re khubd ignoring USB_STATE_NOTATTACHED ]
>
> As I mentioned yesterday, if usb_disconnect() is changed to disable each
> device before processing its children, this issue becomes less important.
> There's also the question of how to prevent the hub release() routine from
> running while the hub is actively in use without incurring deadlock when
> the hub is reset; making the hub driver use usbdev->serialize rather than
> hub->khubd_sem should take care of that.
Yes.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
