On Tue, 31 Aug 2010, Oliver Neukum wrote: > Am Montag, 30. August 2010, 17:12:52 schrieb Alan Stern: > > On Mon, 30 Aug 2010, Oliver Neukum wrote: > > > > > Am Montag, 30. August 2010, 16:42:26 schrieb Alan Stern: > > > > Though the reason is not strong. I'd say it's better to keep both, > > > but not very important. > > > > IIRC your original argument had something to do with file access > > permissions for the attribute files. It's not clear that this is > > really an important issue now. > > Oh yes. Thanks for the reminder. The "level" attribute included > the ability to force a suspension. That could not be exported > to everybody. Now that the third state is gone, the reason is > gone, too. > > Do we gain anything removing it? We'll be forced to retain the > established interface for some time anyway. My thought was that removing this behavior would save a few tests in the PM core. But now I think those tests can be avoided easily enough simply by incrementing the usage_count whenever the timeout value is negative. So there does not appear to be any reason not to keep the behavior. That settles that. :-) Here's a somewhat related question. Consider those buggy USB card readers (when restored to full power, they always report that the card has been changed even if it hasn't). What's the best way to handle them? I see two possibilities. We could simply avoid autosuspend whenever a card is present. Or we could allow autosuspend and then ignore the media-change notification when the reader is resumed. (But I suspect that's not a good idea, since real media changes would be ignored too unless the system constantly polled the device status.) Either way, we'd need the user to tell the kernel what to do. Furthermore, other non-buggy devices with removable media might require special treatment. For example, the user might want to have two different autosuspend timeouts: one for media present and one for media not present. If the media-present timeout is set to -1 then it could have the effect of preventing autosuspend. What sort of sysfs interface should be used for presenting all this to the user? 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
