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

Linus Torvalds
2009-01-16T15:51:11Z

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