On Mon, Jul 7, 2014 at 12:30 PM, Saravana Kannan <skannan@xxxxxxxxxxxxxx> wrote: ... >> Though these are the requirements I have from them: >> - On hotplug files values should get reset .. >> - On suspend/resume values must be retained. > > Hmm... There's actually enough interest in NOT reseting across hotplug > because it's also used by thermal when a CPU gets too hot and then it's > plugged in later. So, userspace has no way to cleanly restore the values. > But that's a separate topic. For Android's usage we're also interested in both: 1. not removing and recreating the cpufreq sysfs files for a CPU on hotplug events (we currently use hotplug uevents to reset file ownership such that power policy can be controlled by non-root). 2. not resetting the contents of policy files such as scaling_max_freq (also fixed up from uevents) or stats files (we currently keep a separate persistent time_in_state for battery accounting purposes). >>> Any objections to leaving them alone during hotplug? If those files are >>> read/written to when the entire cluster is hotplugged off, we could just >>> return an error. I'm not saying it would be impossible to fix all these >>> deadlock and race issues in the current code -- but it seems like a lot >>> of >>> pointless effort to remove/add sysfs nodes. No objections from our standpoint. Thanks -- Todd -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
