On Fri, May 04, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > Driver disconnect() routines need to unlink ALL urbs as well as
> > > make sure that no other driver entries (file operations, say) will
> > > ever try to use that device again (even while unlinking proceeds).
> >
> > Then I hope that disconnect() is not called on an irq!
>
> Only in uncommon error recovery situations, AFAIK. That's is a
> good reason to use async unlink in disconnect() though.
disconnect is guaranteed to only happen in a process context (khubd,
rmmod, etc)
> > ... But if not, then it seems that while it's out,
> > disconnect() might get called. When the process runs again, how will it know
> > not to use that device?
>
> The driver has its own record for each device, tracking opens and
> doing whatever other magic it needs. There's also the usb_device
> pointer.
You can always look at other drivers to see what they do.
> What disconnect() means is: as of this instant, you can't depend on
> being able to do I/O with this device any more. And when that
> disconnect() returns, the pointer becomes invalid/unusable.
Not exactly true. With the reference counting, the pointer can still be
valid. It usually not usable tho since the device is gone now.
> So disconnect() should clear the usb_device pointer in the driver's
> record. That'd be one way that all other execution contexts in
> the driver (timer, sleeping process/thread, etc) would know that
> particular device is disconnected. The driver would free its own
> record of device state when the last context stopped using it.
Or take advantage of the reference counting.
JE
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
