On Sun, 12 Aug 2007, Oliver Neukum wrote:
> > I'm beginning to agree with Matthew Garrett that autosuspend should be
> > disabled by default except for known-good devices and device classes...
>
> We could simply revert to enabling autosuspend only for those devices
> whose driver requests it. Most problems are with devices accessed through
> usbfs.
That's not the point. We're okay with drivers that don't support
autosuspend and we're mostly okay with drivers that do. The problems
seem to fall into two classes:
1. Devices with no driver.
2. Devices that can't suspend but whose driver requests
autosuspend.
Case 1 includes usbfs. However all devices -- other than hubs -- can
fall into case 1 temporarily, if it takes longer than a few seconds to
load their driver module.
(Note that usbfs doesn't support autosuspend. Hence any device claimed
by usbfs won't autosuspend until the device file is closed.)
If a device has no driver then it's logical to assume the kernel knows
nothing about how the device will behave (unless the device belongs to
a known-good class). The safest course is to leave autosuspend
disabled by default and let userspace enable it if desired. This
leaves open the question of what to do when the first driver binds to
the device or the last driver unbinds.
Case 2 is harder; it includes the troublesome printers. For them we
may rely on the quirks list or change the printer driver.
> > Is that good enough? If a printer is plugged in when the system boots,
> > the delay between enumerating the device and loading the driver can be
> > long enough for the device to get autosuspended.
>
> How many devices truely crash?
I don't know. Weren't you the person who added all those entries to
the quirks list?
One of the RedHat Bugzilla reports includes a usbmon log from a
printer, showing that the printer disconnects itself whenever it gets a
resume (and then reconnects a little later). That's almost as bad as
crashing.
Alan Stern
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
