Re: [PATCH] PCI PM: Restore standard config registers of all devices early (was: Re: EeePC resume failure - timers)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Fri, 16 Jan 2009, Alan Stern wrote:
> 
> USB does this.  However I admit that fixing every PCI driver would be a 
> big chore...

I suspect USB is one of the very few drivers that may get suspend/resume 
very close to right, partly because _everybody_ has a USB controller these 
days, partly because USB interrupts are very commonly shared, and partly 
because there are several core people who work on USB.

That's actually very rare (especially the last point - most drivers hardly 
have _any_ maintainer, much less anybody who can see the big picture and 
knows about the rest of the system).

So if everybody did what USB does, we'd indeed be fine, and suspend and 
resume would probably work on practically every machine out there. But as 
you note, it's not really an option. The common case for 99% of all 
drivers is probably that none of the core kernel people can even test 
them, and they likely do not exist even in some distro test area.

So I'm the one who pushed Rafael towards his patch, because we've worked 
on suspend/resume for years, but while we're _much_ better than we used to 
be (especially on machines that are really bog-standard and only have the 
common chips), I don't think we'll ever really "get there" if we rely on 
the drivers always getting things right.

And getting things right does mean changing every single PCI interrupt 
handler to know about suspend/resume - not to mention do the 
suspend/resume sequence right in the first place. Neither of the two is 
very likely to really happen.

I did suggest that we could also add some test-infrastructure like the 
DEBUG_SHIRQ thing we already have, which sends an interrupt immediately on 
resume after interrupts have been enabled. That will likely uncover a 
_lot_ of problems, and it's almost certainly worth doing regardless.

But even then, it would just be so much _simpler_ if the generic layer 
just took care of this issue, so that drivers could just ignore it, and a 
driver would only have to worry about its _own_ resume issues. 

So yes, doing it in the generic PCI layer clearly has some problems, and 
no, it's not "perfect". In a perfect world, doing it in the driver has 
real advantages - it's the most flexible approach, and it allows the 
driver to do what it wants. But from all I've ever seen, I'm personally 
pretty convinced that when it comes to drivers, the less the driver writer 
has to worry about, the better off we are.

I'm franklly hoping that most PCI drivers would not need to have a 
suspend/resume method at all - the PCI layer should get the normal PCI 
suspend parts right, and the upper layers should do the rest. For example, 
a network driver shouldn't have to close itself down - the network layer 
should just do it for it (all the netif_stop_queue() etc crud to make 
sure that the network layer doesn't try to touch it). 

So we're clearly not there yet. But after having yet another random 
machine that just didn't resume because of yet another new random driver, 
I'm just not seeing anything else that is viable long-term.

IOW, we can ask driver writers to write perfect code, or we can spend some 
effort on trying to make things work even when they don't. I know which 
approach I consider to be realistic.

			Linus
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux