On Tue, 27 Dec 2005, Pavel Machek wrote: > On Út 27-12-05 11:29:56, Patrick Mochel wrote: > > But, in some cases, peple are going to care about the intermediate > > states, and we'll need to support them. It's simple enought to know > > what states a PCI device supports, so I don't understand where the > > complexity comes in.. ? > > Someone has to test all that... Unless we have in-tree driver that > wants use intermediate states, I think supporting them is bad idea. I don't understand what your issue is; perhaps you could explain it a bit better. There is no additional work on the part of the core, nor any additional complication in supporting 4 possible power states vs supporting 2 vs supporting any arbitrary number that the driver and device implement. I did not suggest that we make the drivers support intermediate states; I only stated that there are some drivers and devices that can and will implement them, and that there are cases in which it will make sense to enter them from userpsace. If the sysfs files are simply checking string values and making a driver-based call based on the validity of the string, then it doesn't matter a) what the strings are or b) how many there are. I admit I made a mistake in suggesting the interface - we wouldn't want to simply export all the PM states that are present in the device's config space. We would really only want to export the states that the driver says it supports. But, that could be any number of states, above and beyond (or a subset of) D1/D2/D3/etc (or whatever the bus spec says are standard states). As far as testing, how does that factor into the picture? Do you feel that we currently (or will) lack coverage testing? If so, I agree. However, I do not think that should prevent us from thinking clearly about what the best possible solution is. If there is a need for more and/or better testing then we can collectively gather the resources to accomplish it. Thanks, Patrick
