linux-kernel - Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200812071414.13143.rjw@sisk.pl>
Date:	Sun, 7 Dec 2008 14:14:12 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Takashi Iwai <tiwai@...e.de>, Greg KH <greg@...ah.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

On Sunday, 7 of December 2008, Alan Stern wrote:
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> > > Rafael, I'd be happy to help with fixing up the USB PCI PM code.  At
> > > this point I'm not sure exactly what's needed, though.  For instance,
> > > is there any compelling reason to switch over to the new dev_pm_ops
> > > approach?
> > 
> > Certainly not at the moment.  There will be a reason some time after .29.
> > 
> > That said, it apparently is possible to clean up the resume callbacks of PCI
> > USB controllers, as mentioned here: http://lkml.org/lkml/2008/12/6/38
> > 
> > > And what should the correct sequence of calls be?
> > 
> > Well, that's something I'm not exactly sure about myself.  Surely it seems
> > reasonable to call pci_restore_state() with interrupts disabled and do the rest
> > of resume after that.  Also, I think that the core could execute things like
> > pci_enable_device() during resume and pci_set_power_state()/pci_enable_wake()
> > on suspend so that the drivers didn't have to.  This way we could reduce code
> > duplication quite a bit.
> 
> Do you plan to change the PCI core to do these things any time soon?  

I'm going to do that after the patches from this series are merged.

> Wouldn't that require changing a whole bunch of PCI drivers too?

Only those that start to use the new framework before this happens
(which probably is only MMC at this point).

> I tend to agree that having the core take care of these choreographed
> activities would be good -- it would leave less room for drivers to
> make mistakes.
> 
> So for now maybe it would be best just to rearrange the existing calls
> in USB, and wait for the core changes before doing anything more
> ambitious.

Sounds good.

Thanks,
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/