On Mon, 13 Nov 2006, David Brownell wrote: > > Well, I would argue that part of the problem has to do with the use of > > device_may_wakeup. It is tied to a sysfs API > > It's a *driver model* API, which is also accessible from sysfs ... to support > per-device policies, for example the (a) workaround. The mechanism exists > even on kernels that don't include sysfs ... although on such systems, there > is no way for users to do things like say "ignore the fact that this mouse > claims to issue wakeup events, its descriptors lie".
Yes, it is separate from sysfs -- but it is _tied_ to the sysfs API. > > and therefore administrative > > in nature, but now you say it's also being used to record hardware quirks. > > No; I'm saying the driver model is used to record that the hardware mechanism > isn't available. The fact that it's because of an implementation artifact > (bad silicon, or board layout, etc) versus a design artifact (silicon designed > without that feature) is immaterial ... in either case, the system can't use > the mechanism. But the information is being recorded in the wrong spot. The correct test should use device_can_wakeup, not device_may_wakeup. The can_wakeup flag is the one which records whether or not the hardware mechanism is actually available. > > > > If you think autostop should also check for device_may_wakeup(), I'll > > > > make > > > > it do so. Remember though that autostop is intended to work even when > > > > CONFIG_PM is off. > > > > > > The original autosuspend logic would never kick in without PM; after all, > > > it's purely a power saving mechanism! And testing device_may_wakeup() > > > will > > > be restoring that behavior, since without PM that's always false. > > > > It would restore that behavior, and it would be silly way of doing so. > > There are better ways to prevent autostop without PM, such as making > > ohci_rh_suspend() and ohci_rh_resume() depend on CONFIG_PM! > > ISTR they do that too. :) They used to, but I changed it when I added autostop. Looks like I need to change it back. > > However it was always my intention that autostop should operate without > > PM. It's not only about saving power, it also is about reducing load on > > system resources -- primarily DMA, although this may be a lot less severe > > with OHCI than with UHCI. Does OHCI do any DMA at all when no devices are > > plugged in and the schedule is empty? > > That's not an issue at all with OHCI; it only DMAs when the relevant > schedule is enabled. Which it isn't, unless it has work to do. > > > > My quick impression from the spec is that it does not, in which case > > there is no point in keeping autostop when CONFIG_PM is off. > > Exactly. That's why I said it's purely a power saving mechanism. Okay. I'll write a patch to eliminate autostop and those routines when CONFIG_PM is off. But that doesn't answer the question above: Should autostop check device_can_wakeup rather than device_may_wakeup? Also: Does the quirk/bug detection logic clear can_wakeup, as it should? Or does it only affect may_wakeup? 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
