On 18 July 2014 04:57, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote: > First you need to enable sleeping while atomic checking, but in reality, > I assume nobody has tried inserting a cpufreq driver as a module. The I did for sure, but long back. Over 6 months atleast :) > might_sleep() code has a check to see if the system_state is > SYSTEM_RUNNING. If it isn't running then there isn't a warning and > might_sleep() doesn't flag any problem. I wonder if that is actually the > right thing to do though? Perhaps the intention of that code is to skip > warning early on in the boot path when the scheduler isn't up and > running yet. But once the scheduler is running (which is fairly early > nowadays) I would think we want might_sleep() to trigger warnings. Maybe > that check in might_sleep() needs to be updated to check for "scheduler > running" instead of "system running"? > Right. It seems that we moved to RCU in commit > 0f5c890e9b9754d9aa5bf6ae2fc00cae65780d23 so the real Fixes line should be: > > Fixes: 0f5c890e9b97 "PM / OPP: Remove cpufreq wrapper dependency on > internal data organization" Right. > One way to avoid this problem is to put things back the way they were > before that change. Is there any real benefit to having this code live > in drivers/cpufreq/ instead of just under some config option in > drivers/base/power/opp.c? Maybe Nishanth can give more arguments than I can :), but the idea was just to keep cpufreq stuff together.. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
