On 18 July 2014 04:57, Stephen Boyd [off-list ref] 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..