On Wed, Oct 23, 2002 at 05:32:50PM -0700, David Brownell wrote: > > >>I wonder if he'd comment on what it'd mean to call device_unregister() > >>earlier in usb_disconnect() ... like right at the top, not the last > >>thing. The docs imply that'd be OK. > > > > > >Which device_unregister? For the interfaces or the device? > > Well the whole device is DEVICE_GONE, including interfaces, so > whichever order would work.
Please forget about DEVICE_GONE. It will be gone soon from the kernel. I talked Pat into taking that patch, and it was a big mistake. This will be fixed up soon. > Certainly the device itself, since > that's what currently drives the submit logic ... so that's what > would need to know that it's GONE, to let the submit logic reject > new urb submissions. Yes, usb_submit_urb() can just check the device state. But what's to keep the device from being removed _right_ after that check happens. Ah, doesn't work :) That's why we can't rely on a device "state" to determine what we need to do. All we have to work with is a close approximation of the known state, and the reference count of the device. It's not perfect, but it's the real world out here... > There could be a usb-specific notion of state, I guess, but it > sure seems to me like there ought to be one inside the device > registration/etc core logic that USB (and CardBus, PCMCIA, etc) > would rely on. Yes, struct device will get a "device state" type of field, as it is a common thing that all structures need. We just have to use it as a "hint" unfortunately. > >And we need to call device_unregister on our children before ourself, > >like the code currently does. > > But what's the semantics of that "register"? That's what I'm not > clear on. Register to what, and to enable what tasks? There are > lots of things that know about devices. Is anything in the cleanup > path going to depend on that "registration" to be active? Registration only (well, will only in a rev or two) refer to putting the device into the device tree, and removing it. It will have nothing to do with if the device is "present" or not. We need to be able to unregister and then register a device, without tearing it entirely down, and recreating it, as Oliver's config change patch shows (which btw Oliver, is why I haven't accepted it yet, I'm waiting for the driver core changes to get in, otherwise your patch will cause "bad things" to happen). > >But that should not matter, device_unregister() does not do much besides > >remove the device from the driverfs tree. Well, it currently could > >cause the whole device's memory to be freed, but it doesn't :) > > It sets dev->state == DEVICE_GONE, which is useful to know since it > means that the only legal thing to do from there on is clean up. Exactly, that's why we need that, devices (well usb ones at least) can't re-appear after they hit the "gone" state. Hope this helps. I know this is a tricky thing to explain, let along get correct. Pat and I need to go drink some more beer tomorrow and get confused about it again :) thanks, greg k-h ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
