On Tuesday 17 July 2012 22:28:32 Lan Tianyu wrote: > On 2012/7/17 21:48, Oliver Neukum wrote: > > But the driver will not work if you don't use remote wakeup when it needs it. > > Under those circumstances you better unbind the driver. > > > hi Oliver: > Thanks for reply. Why unbind driver? I am sorry I don't understand it. > Can you elaborate it for me? :) The drivers don't request remote wakeup for fun or performance. The driver won't work without it. In consequence a device whose interfaces are not associated with drivers has no drivers to request remote wakeup. > When device is suspended, that means driver will not work, right? No, they will work, albeit slower. That is the point of the whole exercise. Some devices, perhaps because they perform only output, don't require remote wakeup. The others do. > Disable remote wakeup is to keep device being suspended in some > circumstances(system idle) which may be not willing to see device resuming. Then the device will not work with a full set of features. There may be devices which may be able to operate with a reduced feature set without remote wakeup, but personally I can't think of examples. > >> So that means the device's remote wakeup can not be disabled and usb > >> port can not be powered off. So I try to provide a control of remote > >> wakeup to userspace. When system becomes idle such as blank screen, > >> some usb devices may be able to disable remote wakeup and power off. > > > > Yes, this is an unsoved problem. But the approach is no good. Don't > > disable remote wakeup behind the driver's back. Tell the driver that a reduced > > level of service is acceptable. > > > How to tell the driver? That is the big question. In fact, it is not entirely clear whether it makes sense at all. Regards Oliver -- 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
