On Wed, 22 Jan 2014, Dan Williams wrote: > > That's not what I meant. > > > > Sending a request to khubd means doing something like this: > > > > set_bit(port1, hub->resume_child_bits); > > kick_khubd(hub); > > > > khubd may start running even before kick_khubd returns. If it does, it > > will find that the port has not yet returned to power-on status. > > It handles that with pm_runtime_barrier(). When the request bit is > set the port is in the RPM_RESUMING state. We hold a reference and > khubd forces the port all the way to RPM_ACTIVE before checking the > state and dropping references. Ah, yes. I was forgetting about the barrier. Well, we seem to be in agreement on the basic design now. Go ahead and start writing patches. :-) I have a few suggestions. First, begin with a patch that refactors hub_events: Move the guts of the loop over the ports into a separate subroutine. That will make things a little easier to handle. Second, don't bother with the special iterator for the port loop, the one you introduced before. Just put the get and the barrier inline. Third, don't separate out the code that clears the various status-change bits for powered-off ports. Simply handle those bits first, and afterwards skip the rest of the processing if the port isn't powered on Fourth, introduce the runtime PM synchronization and the status_lock in separate patches.. Fifth, don't move the lines that acquire the child device lock. Just drop the status_lock immediately before, and then grab it again after the device is unlocked. Alan Stern -- 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
