On Fri, 17 Jul 2009, Rory Filer wrote: > > -----Original Message----- > > From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] > > > > We already have a per-device sysfs attribute for autosuspend > > management; there's no point in adding a new one to do the same thing. > > > > I think you are referring to the .../power/level attribute. So far, in my > experience "level" is always reset to its default "on" whenever the device > re-enumerates. If there's a way to do a one-time configuration to change the > default from "on" to "auto" then we'll use it as you recommend, otherwise > I don't see how this is any better than the solution we already have. I don't understand this sentence. What do you mean by "a one-time configuration"? Regardless, the initial value is not going to change; it will always be "on". Too many USB devices behave badly for that to be changed. Besides, I don't understand why you want to the change the value from "on" to "auto" anyway. I thought the problem was that a bunch of your modems can't suspend and resume, and hence you wanted to _prevent_ the value from being set to "auto" so that they would work okay. > I don't see how this is any better than the solution we already have. I can't tell what this phrase refers to. Do you mean that Elina's suggestion to add a per-device attribute for controlling autosuspend is no better than having a module parameter? Indeed -- and this was the point I was trying to make originally -- it is no better than the situation even _without_ your module parameter, since there already _is_ a per-device attribute for controlling autosuspend. > And, if such a one-time configuration were available, it is essential that > it only affect the sierra.c driver and not all drivers, globally. I don't understand this either. Try to explain in more detail exactly what you want to accomplish. And don't use ambiguous terms like "one-time configuration". 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
