[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0812060855580.3425@nehalem.linux-foundation.org>
Date: Sat, 6 Dec 2008 09:07:26 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Rafael J. Wysocki" <rjw@...k.pl>
cc: Greg KH <greg@...ah.com>, Ingo Molnar <mingo@...e.hu>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Len Brown <lenb@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Takashi Iwai <tiwai@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume
On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
>
> Rework the handling of suspend and resume of PCI devices which have
> no drivers or the drivers of which do not provide any suspend-resume
> callbacks in such a way that their standard PCI configuration
> registers will be saved and restored with interrupts disabled.
Ok, I think this is good, but I _also_ think that we should do one more
fix:
- if a device uses the new-format suspend/resume structure, we should do
the low-level save-restore _unconditionally_ in the PCI layer.
Because apparently there is only a single user of the new format, and that
single user got it wrong. So wouldn't it be much nicer to just _remove_
the code from the USB host controllers that does the save/restore thing.
Quite frankly, the USB code really does look wrong. Not just in that it
enables the BAR's before restoring them, but on the suspend side it
actually puts the device into D3_hot _before_ it then does the whole
"pci_enable_wake()", which I'm not at all sure will necessarily work. I'm
pretty sure that you should enable wakeup events _before_ going to sleep.
If the generic PCI layer unconditionally did the suspend as the last thing
it does (and the resume as the first thing), then drivers couldn't do
insane things like that, even by mistake.
Hmm?
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