lkml.org 
[lkml]   [2007]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Re: NAK new drivers without proper power management?
    On Sun, 11 Feb 2007, Rafael J. Wysocki wrote:

    > The problem is it was made implicit long ago. The design is "optimistic", so
    > to speak, and I think we have the following choices:
    >
    > 1) Change the design to make the kernel refuse to suspend if there are any
    > drivers not explicitly flagged as "suspend/resume-safe". [This looks like a
    > lot of work to me, but it is generally doable provided that someone has enough
    > time to do it. Unfortunately it has to be done in one shot for all of the
    > known good drivers to avoid user-observable regressions.]

    The kernel wouldn't necessarily have to refuse to suspend. It could just
    warn (and list the drivers that aren't marked), or could require some
    extra insistance from the user. It would be good to have it log a message
    saying something like: "If you can read this, report that ne2000 seems to
    be safe for suspend/resume". Having drivers explicitly marked as to
    whether they are safe is a good kernel feature; what to do if they're not
    is policy.

    > 2) Require the authors of new drivers to _either_ ensure that their drivers
    > will be suspend/resume-safe (and I mean both STR and STD here), _or_ explicitly
    > flag the drivers as "suspend/resume-unsafe", for example by impelenting
    > .suspend() routines returning -ENOSYS. [The existing drivers can be modified
    > to follow this convention gradually.]

    I don't see any reason not to do (2) regardless of (1). That was (my idea
    of) the statement that started this thread: new drivers need to not mess
    up on suspend/resume, as a matter of suitability for inclusion. Of course,
    we need some way for drivers to indicate that they work fine with the
    PCI-layer defaults. And it should probably more machine-readable than the
    author telling reviewers that it works.

    > - Problem what to do with drivers that work for some people and don't work
    > for the others (ie. if we don't flag them as known good, we will break the
    > setups in which they work)

    I think the only interesting case here is when a device resumes fine with
    no driver support if the BIOS manages to deal effectively with it, but the
    BIOS generally doesn't. Otherwise, I think it's only going to work at
    all if the author put in the effort to make it work (so it should be
    "known good"), but there may be bugs (firmware, BIOS, driver, etc). But
    that's true of any functionality.

    -Daniel
    *This .sig left intentionally blank*
    -
    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: 2007-02-11 18:29    [W:0.031 / U:30.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site