On Mon, 24 Jul 2006, David Brownell wrote: > I think PCMCIA switched over to /sys/class/pcmcia_socket/.../card_pm_state > a while back, though I'm not sure about the userspace tools. They could be > behind the times by a bit. > > My autosuspend patches remove the dpm_runtime_* stuff from USB, leaving > > only PCMCIA. > > Good, I was going to ask about that, except that I figured reading the > patches would answer the question in a better way ... ;) > > I have a patch that deprecates the dpm_runtime_*() calls; it's only triggered > by USB and PCMCIA. Not worth submitting IMO; fix the code first, then just > remove those calls since /sys/.../power/state will be the only remaining caller. Dominik, have you been following this? Now's a good time to remove all references to dpm_runtime_*() from the PCMCIA code. > I thought dpm_sem was to protect the list manipulations that are currently > substituting for a more dynamic tree traversal mechanism. (But haven't > actually looked recently...) No, you're thinking of dpm_list_sem. > > And it's not clear that we _do_ want to prevent runtime PM changes from > > occurring during a system sleep transition. > > Real runtime PM changes, of the type the core doesn't see or care about? > Of course not. But the fake ones via sysfs? Yes, I think we do. We > don't want those happening in any case. While userspace is frozen, requests can't arrive through sysfs. So the only time dpm_sem might matter would be when someone on PPC uses the soon-to-be-deprecated sysfs mechanism during suspend-to-RAM! Alan Stern
