lkml.org 
[lkml]   [2006]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs
    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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-11-13 18:19    [W:0.034 / U:0.452 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site