> -----Original Message----- > From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] > > 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. Agreed and we don't want to change it for those products, just for ours and of those, just for the ones of ours which actually work with SS. But we don't want to keep having to make the change every time the module re-enumerates. This is not an unreasonable requirement. If it were, then .../power/level shouldn't even need to exist. > > 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. > Not all of our modems are shipped with firmware and configurations that will permit Selective Suspend to work. A subset of our modems work quite happily with SS. We want one driver to be able to work with _any_ Sierra modem, regardless of that modem's capability. Some modems which today don't work well with SS eventually will. In this case, it is more user-friendly to simply turn on SS by "flipping a switch" which is how it is implemented with this patch submission via the device attribute. You suggested we consider the existing "per-device sysfs attribute for power management"; although you didn't identify which one we guess that you meant .../power/level. Fair enough. We have considered it. Following from our reasoning in the previous paragraph, we would want the default for this attribute to remain "on"; for those modems in which we actually want to have SS turned on, we'd like to have that attribute default to "auto". Further, any actions needed to configure the change to "auto" should only need to be done once, not every time the driver is loaded. Plus, it should only affect this attribute for the sierra driver, not for all drivers in the entire system which have a power directory. We chose to use a redundant control such as the device attribute because that enables us to retain control of whether autosuspend is enabled or not within the driver. The whole system could be configured for SS, but if the modem is not up to it, then it could be bad for the end-user. By our requiring the end-user to switch it on in the driver, they must make the conscious decision to turn it on _for our modem_. Most users neither need nor care about SS. Those who (embedded OEM vendors) really need to squeeze the last drop of power out of their batteries and for them this is a big deal. > > 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? Yes > 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. ... right. And once again you haven't actually identified which one you are referring to. I'll add that we have been working in good faith to accept the suggestions we've been receiving and modify the sierra.c driver cleanly. We are not adding a bug here. We are adding a design feature to the driver which we feel is necessary based on our understanding of our own product. To play devil's advocate, it is a clean use of available mechanisms which were recommended to us by members of the Linux community and in available documentation. So far, the only criticism I've detected is because it is a redundant control. > > 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". What I was getting at was if there actually is a way to change the default setting of .../power/level to "auto", it should affect just the sierra.c driver and not all other drivers at the same time. If not, then this attribute amounts to a global ON/OFF switch like the main breaker in an electrical panel. We want our own breaker independent of the main one. One-time means exactly what it says - you configure your system (i.e. embedded gadget) once and don't need to touch it again. OEMs like this kind of convenience. Anyway, thanks for taking the time to review and sorry that you found our original description of this too vague. We're all having to spend a lot of time on this and I'm sure we all have other things requiring our attention! Kind Regards, Rory Filer, Canada -- 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
