[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201001252226.29289.rjw@sisk.pl>
Date: Mon, 25 Jan 2010 22:26:29 +0100
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Alan Stern <stern@...land.harvard.edu>, Greg KH <gregkh@...e.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
pm list <linux-pm@...ts.linux-foundation.org>,
linux-usb@...r.kernel.org, Arjan van de Ven <arjan@...radead.org>,
Nigel Cunningham <ncunningham@...a.org.au>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Linux PCI <linux-pci@...r.kernel.org>
Subject: Re: [PATCH 2/8] PM: Asynchronous suspend and resume of devices
On Monday 25 January 2010, Alan Stern wrote:
> On Mon, 25 Jan 2010, Rafael J. Wysocki wrote:
>
> > > I intend to write this code, but merging it will be a little tricky.
> > > You'll have to coordinate with Greg KH.
> >
> > OK, I don't think that's a big deal. I can defer patch 7/8 until that code has
> > been merged.
>
> You may have to delay 6/8 as well, since the controllers are PCI
> devices. Writing the new code shouldn't take too long, though.
No problem with that.
Alternatively, if Greg agrees, I can add your patches modifying this into this
series. Greg?
I wonder, though. Since the controllers are PCI devices, we put them into D0
and restore their standard config spaces in the dpm_list order at the "early"
resume stage. Doesn't that help here?
> Is there a good way to iterate through all PCI devices in a particular
> slot, or should it be done by going through all PCI devices and
> ignoring those in other slots? Calling pci_get_slot() multiple times
> doesn't look very efficient.
Hmm, I don't know (added Jesse and Linux PCI to the CC list again).
> > I'll try that, but my mkinitrd automatically puts the USB drivers into
> > initramfs. I guess I'll need to do some research to really verify it. :-)
>
> Then when you install the test kernel, mkinitrd should build a
> corresponding initramfs image with the modified drivers, right?
> Otherwise there would be a version mismatch error when the init code
> tried to load the old drivers into the new kernel.
Yes, but then they are loaded during restore before the image is read and
the hardware is initialized. Would it still fail in that case?
> If nothing else works, you can simply unload the standard uhci-hcd,
> ohci-hcd, and ehci-hcd drivers and then modprobe the modified versions
> before starting the hibernation.
I guess I'll just build a special "restore" kernel without USB support.
Rafael
--
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