Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2006-05-25 at 15:46 +1000, Benjamin Herrenschmidt wrote:
> > This requirement to keep interrupts off in there breaks things again and
> > again and again and again.  And this time: again.
> 
> Where else ?
> 
> If you look at this function it's _designed_ for interrupts off ! the
> driver suspend have the option of deferring their suspend() callback
> until after irqs have been turned off (needed for legacy stuff afaik but
> rarely used) and the sysdev's are very low level things whose suspend
> and resume callbacks should be called after that point as well. 

BTW. The root of the problem with cpufreq is it's upside down design :)
Well, not all of it, but the fact that it registers a sysdev. It's not
the "midlayer" (ugh) business to register devices and hook things like
PM events to pass them down to actual drivers. It should be the cpufreq
drivers themselves that attach to the device model in a way or another
and "instanciate" the ability to control the cpu frequency, passing
along their struct device.

The driver itself should pick the right type of "device" to attach to
(sysdev's are just weird beast and were a bad idea in the first place
since they aren't even struct device).

But then, iirc, that's because we also did the cpu stuff in sysfs upside
down too ... :)

Now, wether the cpufreq notifier might end up calling things that will
sleep or not ... hrm... that's an interesting issue. Part of the problem
is that because cpufreq is a sysdev, it will be called so late in the
suspend process, pretty much everything else is asleep. So I'm quite
confident that things attaching to the cpufreq notifiers other than bits
of cpufreq itself are likely to break anyway. Is it documented anywhere
that registering a cpufreq notifier might cause it to be called in
atomic context or very later in the suspend process (possibly after the
interrupt controller hs been put down) ?

Yes it's messy, no I don't have a miracle solution, but I think here the
proper way to fix it in the long run is for cpufreq not to be a sysdev
or anything like that and to stop trying to do the suspend/resume thing
for the drivers. Drivers are in charge, they get to create the device of
whatever type it is and get the suspend/resume events whenever they are
sent. cpufreq can then provide maybe "helpers" to help work out what to
do at suspend and/or resume time but with the knowledge that for some
drivers maybe, this will happen in atomic context.

Ben.