[lkml]   [2005]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: revert yenta free_irq on suspend

    On Mon, 1 Aug 2005, Dave Airlie wrote:
    > You said earlier we only should fix drivers that need fixing, but they
    > all need fixing

    I think you're still talking from a theoretical standpoing, while all my
    arguments are practical.

    In _practice_, I hope that

    (a) we don't see that very much (ie the people for whom things work
    already are a strong argument that this is less of a problem in
    practice than people try to make it appear)

    (b) drivers, _especially_ on notebooks, are already able to handle an
    incoming interrupt with the device in D3 state and returning 0xff
    for all reads.

    In particular, this is exactly the same thing that you get on a
    surprise device removal too.

    iow it really _really_ shouldn't matter that a shared interrupt comes in
    after (or before) a device has gone to sleep. Because a driver that can't
    handle that schenario is buggy for totally unrelated reasons, and doing a
    "free_irq()/request_irq()" pair at suspend time is _not_ the solution!

    > I'm trying to see which way they should be fixed, either the PM people
    > say we need request/free irq pairs or say we need to put support code in
    > the interrupt handlers,

    And I say that's not true. See (b) above. As far as I can tell, the
    "interrupt when in D3" really looks _exactly_ the same as "interrupt when
    device was just removed by the user", and nobody will hopefully argue that
    free_irq/request_irq can protect against forced removal?

    > This has nothing to do with the issues with highlevel PM interfaces
    > for shutting down hardware, this is do with fixing the drivers in the
    > kernel currently and what the correct way to do it is without breaking
    > someone elses hardware....

    ... and I don't think this has _anything_ to do with free_irq/request_irq,
    and everything to do with the fact that we can try to make at least the
    common drivers "hardened" for unexpected interrupts coming in when the hw
    might not be ready for them.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.032 / U:32.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site