Re: PCI PM: Restore standard config registers of all devices early

[Linus Torvalds]

On Tue, 3 Feb 2009, Benjamin Herrenschmidt wrote:
> 
> IE, you should have something to ensure, before you turn interrupts off,
> that nobody else is inside the AML interpreter. You already know there
> are no other CPUs, so it's just a matter of making sure no other process
> has scheduled while holding that mutex.
> 
> The easy way to do that is to do something like taking the mutex
> yourself and then setting a flag so that the intepreter stops trying to
> take it or release it itself, maybe just using the global system state.
> 
> Then release the mutex on resume.

Why do you think this improves on anything?

Basically, it turns the mutex into a non-entity - but if your whole 
argument is that it might as well be a non-entity because nobody else can 
take it anyway, then why not just leave it around?

IOW, if your argument boils down to "there can be no contention", then you 
might as well say "just use the mutex, it will never block".

So the only thing you really need is to just disable the _debugging_ code 
that mutexes have (if they get built with debugging in the first place). 

I can't find the bothersome code anyway: I do find

	DEBUG_LOCKS_WARN_ON(in_interrupt());

but that's just saying that you shouldn't be using mutexes from 
interrupts, not from irq-off segments. There's probably something I'm 
missing, like the preempt_check_resched() causing a schedule event with 
irq's disabled, and the "might_sleep()" thing. But the latter should 
already be disabled by the "system_state != SYSTEM_RUNNING" thing.

Oh, except we don't seem to have a SYSTEM_SUSPEND thing. Is that what 
people are complaining about?

Just do

	system_state = SYSTEM_SUSPEND;
	..
	system_state = SYSTEM_RUNNING;

around the irqs-off section in suspending if so.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/