On Thu, 13 May 2004, David Brownell wrote: > > There's just one or two loose ends to consider, like what happens if a > > device is unplugged during a reset. We don't want hub_port_init() in the > > reset thread deleting the usb_device structure; that should be left up to > > khubd. > > Right. You're going over the reset stuff anyway, > so I'm sure you can come up with a solution.
Yes. There are a couple of things like that. Mainly it's a simple matter of moving code from one subroutine to another. > > We _can't_ use hubdev->serialize to lock ports. (Fortunately we don't > > have to, and using the child's lock is just as simple.) The reason is > > clear: Sometimes a thread will need to lock a port while already holding > > the child device's lock. If that meant locking the hub, it would involve > > acquiring locks in the wrong order. > > Those "sometimes" cases are the responding/initiating changes > cases, right? I'm not sure what you mean by "responding/initiating changes" -- the cases I had in mind were suspend, resume, and reset. In all three the caller has locked the device and we will need to send a message to the device's hub port. In the case of reset particularly, it's important to make sure that the port status changes occurring as a result of the reset don't cause khubd to interfere in any way. > > No, usb_probe_interface() doesn't need to lock anything. The locks will > > already have been acquired, either by usb_register() or by the caller of > > usb_set_configuration(). (There's another obscure pathway to consider, > > USBDEVFS_CONNECT -- it should be treated the same as usb_register().) > > > > Maybe you're thinking that once you hold the writelock you still need to > > hold dev->serialize? That's not necessary. Holding the writelock will > > prevent everyone else from locking _any_ device. > > I was thinking you still wanted to ensure that probe() was always > called in the same kind of context ... including dev->serialize. I'm abstracting the idea behind dev->serialize. From now on, instead of talking about owning dev->serialize we should talk about locking the device. Locking can take either of two forms: holding the writelock, or holding the readlock plus dev->serialize. On this abstract level the context of probe() _is_ always the same: It's called with the device locked. Ditto for disconnect(), suspend(), and resume(). Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
