On Thursday, December 05, 2013 06:11:19 PM Srivatsa S. Bhat wrote: > On 12/05/2013 12:27 PM, Bjørn Mork wrote: > > Viresh Kumar <viresh.kumar@xxxxxxxxxx> writes: > > > >> Sending from phone.. html.. so left list. > >> > >> Here is the old thread where we discussed this.. see if this helps.. > >> > >> http://marc.info/?t=136845016900003&r=1&w=2 > > > > Thanks. That helped a lot. > > > > Unless I miss something, it looks like the permission problem *started* > > with fallout from special suspend code - surprising the user by not > > creating any offline/online event on suspend/resume. Quoting from > > http://marc.info/?l=linux-pm&m=136847781510358 : > > > > (And yes, even code-wise, we use a slightly different > > path in the S3 code, to initiate hotplug. That's why the uevents > > are by-passed.) > > > > I hope you didn't miss the main idea I was trying to convey in that > reply: > "IMHO, using CPU hotplug (offline/online of CPUs) in the S3 path is > supposed to be totally internal to the suspend/resume code. It is not > intended for userspace to know that we are internally offlining/ > onlining CPUs." By the way, in the meantime I discussed this with Viresh in the context of a different (although related) fix and I suggested a different approach. Namely, to split the CPU offline/online code into "core" and "add-ons" parts, where the core part will do just whatever is needed to offline/online CPU cores cleanly and the "add-ons" part will carry out the rest (e.g. removal/addition of sysfs attributes and so on). Then, the system suspend/resume code path will only run the "core" part and whatever else CPU handling is needed during suspend/resume will be carried out by the device suspend/resume code (via driver callbacks or stuff similar to cpufreq_suspend() and cpufreq_resume() recently proposed by Viresh). In turn, the "runtime" CPU offline/online will carry out both the core and the add-ons parts as it does today. In my view this should address the problems we have with sysfs attributes, governors start/stop etc. during system suspend/resume. Thanks, Rafael -- 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
