> -----Original Message----- > From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] > Sent: Saturday, July 18, 2009 7:50 PM > > On Sat, 18 Jul 2009, Rory Filer wrote: > > > (And by the way, there's nothing special about _selective_ suspend. > System-wide suspend works exactly the same way, as far as the device is > concerned.) Sorry, I am using that SS term the same way some other people use TCP/IP to refer to the entire suite of internet protocols. > > Also, what change don't you want to make? Do you mean that you don't > want the driver to change the power/level attribute? Why not? Surely > you're not worried about the extra work this would entail for the probe > routine. Changing a single variable's value isn't exactly going to > cause the CPU to overheat and melt down. :-) Even if we did want the driver to change .../power/level (and BTW, we'd rather gnaw our left arms off than actually do that) the driver would need to do it based on some criterion. The fact is at the moment we can't probe our device to determine its ability to work with SS - this will be available in a future firmware release, but of course this change needs time to percolate through. We need a solution that works now. Perhaps this has been the source of all your confusion to date? Anyhow, the Device Attribute we have put into the driver with this patch submission provides the flag the driver will use to make this decision for now. Eventually when the firmware supports it we can/will deprecate the attribute. > > > This is not an unreasonable requirement. If it were, then > > .../power/level shouldn't even need to exist. > > As a matter of fact, drivers aren't supposed to change the power/level > value at all. For the record, we have _never_ suggested we wanted to do this in the driver. > > > 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. > > (Don't you mean "module parameter" rather than "device attribute"?) Yes, my bad. But// if we were to make the change to a device attribute and then resubmit this patch, would it make any difference? > > "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". In fact, we do care if it means we can implement a solution once instead of our customers implementing the same solution in various ways. It saves them having to re-invent the wheel and it makes our life easier for tech support. > > > 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. > > Normally this sort of configuration is done in userspace by programs > like udev or hal. It's not hard to write a udev rule that will set > power/level to "auto" for all Sierra modems and nothing else. Then the > "one-time configuration" simply amounts to a decision as to whether the > rule should be installed. > > A more flexible rule might even be capable of setting power/level to > "auto" only for Sierra modems with good firmware. OK, this sounds promising. We haven't any experience with UDEV yet so... How safe is it to assume that all 2.6.x kernels will contain udev? I'm thinking particularly of embedded systems here. In many cases customers roll-their-own kernel. They often are reluctant/unable to change their kernel for reasons of backward compatibility; if they haven't got UDEV/HAL built-in then we'd have to slip them a "special" copy of our existing driver :) This brings up another point I've been forgetting to mention. Whatever our solution, it is far preferable for it to work the same way across all kernels. I think UDEV is a good candidate for this, subject to my above concerns. Our Module Parameter is also such a solution. Regards, 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
