On Sat, 14 Oct 2006, Benjamin Herrenschmidt wrote: > Well, we have two different things here. > > One is short term block. For example, PM transitions, or BIST. In that > case, I reckon it might be worth just making the user space PCI config > space accessors block in the kernel during the transition (a wait > queue ?) That seems like a reasonable thing to do. (BTW, can anyone explain quickly what "BIST" means?) > One is long term block: the device is off. That's where it becomes > tricky. For D3, I suppose it's actually correct to return cached infos > provided that those do actually cache the PM capability indicating D3 > state (that is we need to update the cache after the transition). And > it's correct to prevent writes too I suppose. > > Then there are problems with things like embedded or some Apple ASICs > where we toggle power/clock lines of devices but not directly using PCI > PM (in fact, those devices might not even have PCI PM capability > exposed). Returning cached info is fine, but we can't tell userland > about the powered off (or unclocked) state of the device that way. Now you're starting to tread in the dangerous waters of runtime PM userspace APIs. So far nobody has figured out a good general way of exposing internal power states to userspace. There may not even be such a thing. Alan Stern
