> On Friday, July 09 2009 Greg wrote: >Do the autosuspend on a per-device basis, not allowing it for devices that do not support it. >As you know which ones do and do not handle this properly, just add them to the tables in the >driver. Hi Greg, Thanks. The sierra.c driver is sufficient to interact over USB interfaces for all of our modem products, so one driver fits all. However many of our modems today do not support Selective Suspend – they may crash or behave unpredictably when suspended - but they may eventually support it. Creating two separate drivers, one for SS modems and another for non-SS modems is not an option either because of the configuration management nightmare that would create. We also do not want to make any assumptions about the way a particular Linux kernel is configured for Power Management; our experience with Ubuntu is that power/level is ON so far, but other distros may be different. We like to retain some control over our own destiny by using the module parameter as a kind of master-enable. The default setting is to disable autosuspend so that the majority of users of this driver don’t see problems if Autosuspend is somehow enabled on their system. Those who want Selective Suspend and who know what they are doing can enable the parameter in the driver. So far, of all our customers, only one needs this feature and that’s why we’ve been working so hard on it lately. As far as whether a driver-wide or a device-wide parameter is the way to go, I think you could argue it either way. But since implementing it on a per-device basis can be configured to work the same as the driver-wide case, we are looking at ways to do this. One approach is to add a device attribute with read/write capabilities that will have specific value based on the device. We’d be interested in getting your opinion as to whether this approach may meet with further opposition. Regards, Elina Pasheva Rory Filer -- 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
