On Mon, 20 Jul 2009, Rory Filer wrote: > 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? Part of it, but not all. 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. > 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. What will happen when revised kernels (after the attribute is removed) encounter old firmware? > > (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? To some extent it would. A device attribute is better than a module parameter because it allows the user to customize individual devices when more than one is present. On the other hand, a device attribute would be completely redundant with the existing power/level attribute. 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. > > "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. Then implement your solution once and distribute it to your customers. If you implement it in the form of a userspace program rather than a driver change, everyone will be happy. > > 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? What's the exact opposite of "safe"? :-) As a matter of fact, udev isn't part of the kernel at all. It's a userspace program, or rather, a suite of programs. > 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 :) Embedded systems often don't include udev. However when they don't, it's generally because they don't support hotplugging -- all the devices they will use are detected during system startup. So for these systems you would want to provide a shell script that could be run at the end of the system startup sequence, to set the power/level attribute to "auto" for all devices managed by the sierra driver. Such a script would be very easy to write; it wouldn't require more than about two lines of code. > 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. udev is a good candidate because it isn't part of the kernel at all; hence it definitely works the same way across all kernels. A shell script has the same advantage. 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. 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
