On Sun, 12 Aug 2007, Oliver Neukum wrote: > Am Donnerstag 09 August 2007 schrieb Alan Stern: > > Oliver and Pete: > > > > Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries > > for scanners with a single class-wide entry? > > Which class? It would have to blanket all vendor specific devices. > This is a rather broad swipe.
I was hoping there would be a specific device class for scanners. Oh well. I'm beginning to agree with Matthew Garrett that autosuspend should be disabled by default except for known-good devices and device classes... > > What about printers? > > Just remove the autosuspend support from the driver if you really > want to do this. 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. > > Would a USB_QUIRK_RESET_RESUME entry suffice or do we really need > > NO_AUTOSUSPEND? > > Having no way to test, I am conservative. Besides, is RESET_RESUME > the right thing to do for a device driven by usbfs? It would turn close() > into an operation that can cause a reset as a side effect. There's nothing wrong with that. The kernel makes no guarantees about what happens to a device driven by usbfs while its file is closed. The next program to open the file can't depend on finding the device in any particular state; this has always been true. 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
