Re: Totally broken PCI PM calls

[Paul Mackerras]

Linus Torvalds writes:

> On Mon, 11 Oct 2004, Benjamin Herrenschmidt wrote:
> >
> > Any reason why this totally broken code was ever merged upstream ?
> 
> Because it fixes a lot of drivers.
> 
> > Please, revert that to something sane before 2.6.9...
> 
> Nope. There's just too much confusion abou what the state thing means. 
> See the TG3 driver, for one, all the USB drivers for another.

The USB drivers aren't a good example, they are currently quite broken
as far as suspend/resume is concerned.  They used to work just fine
but got broken some time in the last few months.

The problem I have at the moment is that PCI drivers get asked to go
to D3 for both suspend-to-ram and suspend-to-disk.  In particular the
radeonfb driver wants to do different things in these two cases.

Really, what is bogus is pci-driver.c thinking it can tell what state
to ask the PCI device driver to put the device into from the system
power state, without using any platform information.  For suspend to
ram, we may need to put devices into D2, D3hot or D3cold, depending on
the motherboard design.  For suspend to disk, we don't really want to
change the device's power state at all, but just quiesce the device
and save its state.

In the radeonfb case, it needs to put the device into either D3hot or
D3cold (depending on the motherboard design) for suspend to ram.  For
suspend to disk it doesn't want to do much of anything (otherwise we
lose the console at that point).

> The long-term solution is to make this thing be not a number at all, but a 
> restricted type (ie a "struct" with one member, or similar) to make sure 
> you _cannot_ mis-use it. As it is, most PCI drivers do seem to expect a 
> PCI suspend state. 

Maybe the real problem is that we are trying to use the device suspend
functions for suspend-to-disk, when we don't really want to change the
device's power state at all.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/