On Sunday, July 29, 2012, Alan Stern wrote: > On Sun, 29 Jul 2012, Rafael J. Wysocki wrote: > > > The difference is, if you use _put_sync(), you need to wait the extra 10 ms > > for local_pci_probe() to return (if the parent is actually suspended), > > although you might not need to wait for it if you used _put(), right? > > Yes, that's the difference. But who waits for local_pci_probe() to > return? :-) pci_register_driver() might, but that's not a big deal. Hot-plug might as well, though. > > Which, to me, means that using _put_sync() may not be always better. > > It probably doesn't matter a lot, but then the workqueue overhead shouldn't > > matter a lot either. > > It's that in the end, the extra overhead is pretty small. For me > there's also an issue of style: If you do a synchronous get then it > looks odd not to do a synchronous put. My feeling has always been that > the async routines are for use in non-process contexts, where the sync > routines can't be used. Using them just to return a little more > quickly is a foreign idea. I see. :-) The reason for using sync get is quite obvious: we want to be able to access the device later on. For sync put that's not so clear, though. There are cases when we definitely want to do it, like the failing .probe() in which we want to disable runtime PM next to the put, but usually it doesn't hurt (too much) to defer it IMO. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
