[lkml]   [2007]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] PHYLIB: IRQ event workqueue handling fixes
    On Wed, Oct 17, 2007 at 10:58:09AM +0200, Jarek Poplawski wrote:
    > 8) phy_stop_interrupts(): I'm not sure this additional call from
    > DEBUG_SHIRQ should be so dangerous, eg.:
    > /*
    > * status == PHY_HALTED &&
    > * interrupts are stopped after phy_stop()
    > */
    > if (cancel_work_sync(...))
    > enable_irq();
    > free_irq(...);
    > /*
    > * possible schedule_work() from DEBUG_SHIRQ only,
    > * but proper check for PHY_HALTED is done;
    > * so, let's flush after this too:
    > */
    > cancel_work_sync();

    After rethinking, it looks like this last cancel should be useless.
    So, if phy_interrupt() schedules only if !PHY_HALTED and phy_change()
    does enable_irq() with no exeptions, it seems phy_interrupt() even
    without lock must see PHY_HALTED state before this free_irq() with
    possible DEBUG_SHIRQ call, then maybe only this safety:


    Btw, I've read this was considered and not liked, but IMHO, if this
    really has to be like this, creating phy's own workqueue seems to be
    resonable, at the very least to reduce latencies to other users of
    this irq.

    Jarek P.
    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: 2007-10-18 08:31    [W:0.021 / U:47.792 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site