lkml.org 
[lkml]   [2002]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-usb-devel] Re: device model documentation 2/3
     > > All calls are made with interrupts enabled, except for the
    > > SUSPEND_POWER_DOWN level.
    >
    > This is a slight problem for USB. We need to switch on interupts
    > to send a message to the device.

    For example, to enable remote wakeup (whenever we start to
    support that). I understand that a lot of USB hardware does
    not work reliably if that's enabled much before a USB suspend.
    If only SUSPEND_POWER_DOWN notification was delivered, that'd
    have to be enabled at that point.


    >>Why would you allocate memory on a resume transition?

    One example comes to mind. There are systems that, rather
    than supporting a "suspend to reduced power", are actually
    set up so they "suspend to no power". Or in short, they
    power off in cases when other systems don't ... saving even
    more power. (I think that is the difference between D3hot
    and D3cold, or somesuch, but there are so many different
    names for the various states and contexts that I've been
    known to get them wrong.)

    In that case, a "resume" needs to be able to completely
    re-initialize the hardware. As a rule, that's going to
    want to be able to allocate memory.

    ... though FWIW I missed seeing anything that showed how
    those API summaries would place constraints on allocating
    memory, so I didn't assume there could be any.


    What did seem to be missing was anything saying whether
    those device methods would be called in_interrupt() or
    whether instead they could sleep. I'd hope all of them
    would be specified to allow blocking as needed, like their
    current analogues in PCI and USB.

    Also, there was some mention not that long ago about
    desirability of some kind of device abort() call. That
    would differ from the current remove() call because an
    abort() would pass the explicit knowledge that hardware
    was gone ... unplugged before driver shutdown, for one
    example. That could also be achieved using some kind
    of mode parameter to remove() -- perhaps three values,
    saying whether the hardware was present, removed, or
    in some indeterminate state.

    - Dave

    -
    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: 2005-03-22 13:26    [W:0.025 / U:155.576 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site