On Wednesday 01 March 2006 01:38, Greg KH wrote: > On Mon, Feb 27, 2006 at 11:18:43AM -0800, Patrick Mochel wrote: > > > > On Tue, 21 Feb 2006, Greg KH wrote: > > > > > On Mon, Feb 20, 2006 at 04:55:34PM -0800, Patrick Mochel wrote: > > > > > > > > Hi there, > > > > > > > > Here is an updated version of the patches to fix the sysfs interface for > > > > runtime device power management by restoring the file to its originally > > > > designed behavior - to place devices in the power state specified by the > > > > user process writing to the file. > > > > > > > > Recently, the interface was changed to filter out values to prevent a > > > > BUG() that was introduced in the PCI power management code. While a valid > > > > fix, it makes the driver core filter values that might otherwise be used > > > > by the bus/device drivers. > > > > > > Are there any existing bus/device drivers that are currently broken > > > because of this change? > > > > It's difficult to tell. There are several devices that support multiple > > PCI power states, and several drivers that will attempt to put the device > > into whatever state is passed to their ->suspend() method. But, there are > > not many that handle D1 or D2 specially. > > > > The point of the patches was to restore the functionality of the sysfs > > file to its documented interface, which had been that way since the file > > was created (early in 2.6). In the last year, since the conversion to the > > pm_message_t in driver suspend methods, it is not behaved as it was > > advertised to do. > > > > One solution is to prohibit any suspend/resume commands besides "on" and > > "off", and to change the documented semantics of the file. But, it seems > > much more useful to enable the use of the intermediate states, so long as > > it doesn't do any serious harm. Put another way, it doesn't seem to make > > sense to intentionally prevent the use of intermediate power states. > > > > What is also a bit wonky is the handling of those intermediate power > > states now. If someone has a PCI device that advertises D1/D2 support, and > > he/she knows the driver supports it (or is writing the driver support for > > it), a write of "1" or "2" to the device's state file is not going to > > provide the type of behavior that one would expect.. > > > > Does that help at all? > > Hm, no. As nothing can be proven to be broken right now, it's way too > late to get any change like this into 2.6.16-final. Especially as your > patch series broke Andrew's laptop :) And mine too, FWIW. ;-) Greetings, Rafael
