> -----Original Message----- > From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] > Sent: Monday, July 20, 2009 11:29 AM > > On Mon, 20 Jul 2009, Rory Filer wrote: > > Are you going to change the firmware so that the ability to suspend > can be determined from the idProduct and bcdDevice values? (That > is, it would not be necessary to actively query the device but only > to look at the device descriptor?) You definitely should. We'll look at the idea of using bcdDevice in this way. > So given that your proposed solution is worse than the redundant > solution, and that the redundant solution is (by definition) worse than > the existing situation, I don't see any need to change the driver at > all. Agreed. Finally! Given enough time, meditation and vacation, enlightenment gradually ensues. There remain two quibbles to using the .../power/level (or the other) attribute; first, the current setting of "ON" may not always remain that way. There have been precedents in the past for things changing unexpectedly from one release of kernel to the next (e.g. system tick interval). So I wouldn't say it's impossible for someone to get the bright idea to change ON to AUTO or something else in future. Second, the solution for changing it to AUTO when it actually needs to be changed to AUTO needs to differ depending upon what services are installed in a particular user's system. > > > > "Default" is not a good word to use. You want the value to end up > > > being "auto". You don't care (or you shouldn't care) whether it ends > > > up that way because that was its initial value or because some program > > > or driver changed it from "on" to "auto". Well under certain circumstances we do want it to be Auto, but most of the time we (or our customers) don't. The concept of a default value of any variable is valuable - even to whomever decided to make the initial setting/ default value (or whatever you want to call it) of .../power/level = ON and not something else. > Your module parameter isn't such a good solution because it would _not_ > work the same way across all kernels. It wouldn't work at all for > kernels before 2.6.31, then it would work for some indefinite number of > kernels to follow, and then for even later kernels it would once again > stop working. Actually, it does work all the way back to 2.6.23 because we've tested it, so I'm not sure what you are getting at here. In any case, we've decided to get rid of it for now and will use the existing power attributes, so it's a moot point. I've just returned from a short vacation - hence the delay in preparing this response. We have some unfinished business with Oliver's comments as well, so on to those next. Thanks for all the reviewing. Regards Rory -- 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
