On Sat, 4 Sep 2010, Rafael J. Wysocki wrote: > > That's not how I'd like it to work. When the use_suspend_delay flag is > > set, there should be no way around it. The PM core _will_ enforce this > > minimum idle time before allowing runtime suspends. If you want to > > ignore last_busy then you have to call > > pm_runtime_dont_use_suspend_delay (to be renamed > > pm_dont_use_autosuspend or something like that). The driver can't > > easily choose to ignore suspend_delay on a one-time basis. > > I don't see a valid reason for this restriction. Moreover, I'm anticipating > situations where it will be inconvenient. > > Consider an Ethernet adapter. It's driver may very well want to use > autosuspending, but if the network cable is detached from the device, > it makes sense to suspend it without taking last_busy and friends into > consideration. That's a good example. Unplugging a network cable is a major physical change, comparable to removing the medium from a storage device. Depending on how the ethernet driver is designed, it might indeed choose to call pm_runtime_dont_use_suspend_delay when it first detects an unplug event. Or, if there are valid reasons for putting the adapter back to full power on occasion even while the cable is unplugged, the driver might choose instead to switch to the alternate delay value, which could be very short but still larger than 0. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
