On Fri, 17 Jan 2014, Dan Williams wrote: > > The basic idea of using runtime PM synchronization to prevent khubd and > > port power operations from interfering sounds good, and it is simpler > > than adding a new mutex. And I think we can also use it to prevent > > port power operations and port resets from interfering. But that > > leaves open the question of how to prevent usb_device_reset from > > interfering with khubd. > > > > Yes, patch 9 narrowly addresses a problem that needs a wider solution. > > We want to: > > 1/ prevent khubd from running while reset is in progress This is the open question mentioned above, if you add in the requirement that we also want to prevent a reset from starting while khubd is running (except when khubd performs the reset itself). > 2/ prevent khubd from seeing an intermediate device state during > usb_port_resume khubd doesn't pay all that much attention to device states; mostly it is concerned with port statuses. We don't want khubd to see an intermediate port status during usb_port_resume. Basically that means we don't want khubd to run while usb_port_resume is in progress, and we don't want usb_port_resume to start while khubd is running unless khubd performs the resume itself. > 3/ prevent khubd from running in the interval between completion of > ubs_port_runtime_resume() completing and usb_port_resume() running. Hmmm. I don't remember what usb_port_runtime_resume does about a connected USB-2 child device. It can't simply do a runtime resume of the child. Maybe it should tell khubd to resume the child? Then khubd would never see the intermediate state; the next time it looked at the port, it would issue the runtime resume. (Provided that usb_port_runtime_resume didn't complete after khubd was already running.) > All these scenarios to point to problems with ->device_state collisions > not necessarily the port state. I don't think so, for the reason mentioned above. And it is starting to seem less likely that we can rely on runtime PM synchronization to do everything we want. For example, if something is suspended then there is no way to prevent a runtime resume from occurring at any moment. > How about a new lock that synchronizes > device state changes with state checks? This replaces patch 9, only > compile tested: When considering overall strategies for solving a problem, I find that posting patches is almost never helpful. A patch focuses the mind on low-level coding details, many of which are irrelevant to the problem at hand, preventing you from concentrating on the overall picture -- which is the most important thing at this stage of planning. Pseudo-code can be better in this regard, and I sometimes use it when a degree of precision is necessary in the discussion. However, I don't think we have reached that point yet. Therefore I would greatly prefer if you could describe in prose what you want to do. 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
