On Fri, May 11, 2007 at 06:59:31PM +0530, Satyam Sharma wrote:
> [1] This is the first problem point. However, I didn't find any reason
> why this particular driver's .disconnect() couldn't sleep. In fact, a
> comment in include/linux/usb.h:811 says:
>
> "The probe() and disconnect() methods are called in a context where
> they can sleep, but they should avoid abusing the privilege. Most
> work to connect to a device should be done when the device is opened,
> and undone at the last close. The disconnect code needs to address
> concurrency issues with respect to open() and close() methods, as
> well as forcing all pending I/O requests to complete (by unlinking
> them as necessary, and blocking until the unlinks complete)."
>
> I'm assuming the comment is not obsolete, of course, but although the
> first sentence says .disconnect() shouldn't abuse the privilege to
> sleep, the last sentence makes it quite evident that we are _allowed_
> to do so anyway, and that is how things are (with the hci_usb driver,
> at least, I didn't check the .remove() or .disconnect() functions of other
> USB drivers, however).
Yes, this is true, you are running in thread context for .disconnect of
usb drivers, so you can sleep if you need to, but you will block all
other device's disconnect and probe functions while you do. So, it's
good to try to not abuse this if possible.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]