On Sat, 10 Feb 2007, Oliver Neukum wrote: > > The problem is that after the device is suspended, we don't know whether > > it was an autosuspend or the result of an external user command. (It > > If that is true then we cannot know whether to wake up on demand. > I am afraid that state will have to be recorded.
No -- we always wake up on demand, regardless. A "demand" can take either of two forms. One is a remote wakeup request from the device itself. Such a request will be sent only if remote wakeup was enabled at the time the device was suspended. We don't need to remember the state; the device will remember it for us. The other form is a software resume request bubbling up from one of the device's children. (Example: A hub with a mass-storage device connected to it. If the block layer wants to do I/O to the child device then the hub has to be resumed.) Such requests must always be carried out (as the example shows). > > > Secondly, how about exposing USB_IF_DEVICE_BUSY through sysfs? > > > > It's constantly changing. The value exposed wouldn't be reliable. (Or > > for devices where it's not constantly changing, the value is always 0 and > > hence uninteresting.) > > Then interesting direction is writing, not reading. Why would anyone want to write it? Especially since you can force the device to suspend or resume whenever you want, anyway. > > > > + if (value) > > > > + rc = usb_bus_type.suspend(dev, PMSG_SUSPEND); > > > > > > Thirdly, doesn't this have security implications? You can shut down > > > network interfaces and swap spaces this way. > > > > Yes indeed -- just like many other sysfs interfaces, such as > > bConfigurationValue. That also is capable of shutting down network > > interfaces and swap spaces. > > True, but it means that the security implications are still different. > You cannot rely on this interface to resume devices from user > space. Therefore the delay interface should resume the device. I don't follow your argument. Why does the "delay" interface (more properly, the "autosuspend" attribute) need to be able to resume devices? There are other ways to resume them from userspace. Opening a device's usbfs file will do it, for instance. (Running lsusb resumes _every_ USB device.) Or simply trying to use the device, since it will resume on demand. Alan Stern ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
