[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0912151051580.14385@localhost.localdomain>
Date: Tue, 15 Dec 2009 10:57:25 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Alan Stern <stern@...land.harvard.edu>
cc: "Rafael J. Wysocki" <rjw@...k.pl>, Zhang Rui <rui.zhang@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: Async suspend-resume patch w/ completions (was: Re: Async
suspend-resume patch w/ rwsems)
On Tue, 15 Dec 2009, Linus Torvalds wrote:
>
> And even when you know it's PCI, our rules are actually not simple at all.
> Our rules for PCI devices (and this strictly speaking is true for bridges
> too) are rather complex:
>
> - do we have _any_ legacy PM support (ie the "direct" driver
> suspend/resume functions in the driver ops, rather than having a
> "struct dev_pm_ops" pointer)? If so, call "->suspend()"
>
> - If not - do we have that "dev_pm_ops" thing? If so, call it.
>
> - If not - just disable the device entirely _UNLESS_ you're a PCI bridge.
>
> Notice? The way things are set up, if you have no suspend routine, you'll
> not get suspended, but you will get disabled.
Side note - what I think might be a clean solution for PCI at least is to
do something like the following:
- move that "disable the device entirely" thing to suspend_late, rather
than the earlier suspend phase. Now PCI devices without drivers or PM
will not be touched at all in the first suspend phase.
- initialize all PCI devices to have 'async_suspend = 1' on discovery
- whenever we bind a driver to the PCI device, we'd then look at whether
that driver implements suspend/resume callbacks (legacy or new), and
clear the async_suspend bit if so.
That way we'd have the same old synchronous behavior for all PCI suspend
and resume events (unless the driver itself then sets the async_suspend
bit at device init time, which it could do, of course), while still always
doing async "no-op" events.
That would avoid the ugly one-liner that just "knows" that PCI bridges are
special and don't do anything at suspend time (even though they aren't
really - a PCI bridge _could_ have a driver associated with it that does
something that might not be happy being asynchronous).
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists