Re: [PATCH] fix tulip suspend/resume

Benjamin Herrenschmidt
2005-06-07T05:56:11Z

>
> I think unregistering the handler is the equivalent and easier to get
> right. Otherwise, the driver developer needs to check a flag in the
> interrupt handler to see if the device is sleeping, and if it is then
> return IRQ_NONE. Both options would work fine, but I don't see a race
> condition with free_irq().

You still need to disable IRQs on chip tho before you free_irq or you'll
put other devices sharing your interrupt in real pain in case your hw
accidentally emits one :)

> > To not be racy, the best is to synchronize though. Something like this
> > pseudo code:
> >
> > suspend():
> >
> > 1) chip_disable_irq(); /* disable emission of IRQs on the chip,
> > * maybe do that & below in a spinlock_irq
> > * to make sure no other driver code path
> > * re-enables them
> > */
> >
> > 2) me->sleeping = 1; /* tells the rest of the driver I'm not there
> > * anymore, can be some netif_* thingy.
> > */
> >
> > 3) synchronize_irq(me->irq); /* make sure above is visible to IRQs and
> > * any pending one competes on another
> > * CPU
> > */
>
> free_irq doesn't return until all pending irqs have completed, so we
> don't need to do this if we're using the method I proposed. In fact,
> I think it calls synchronize_irq.

Yes. free_irq above would be equivalent to synchronize_irq() and a good
replacement for it. With it, you don't even need the me->sleeping & test
in the IRQ handler since you simply cant call the IRQ handler after it's
free'd :)

> >
> > 4) pci_set_power_state(), maybe free_irq(), etc...
> >
> >
> > my_irq_handler():
> >
> > if (me->sleeping)
> > return IRQ_NONE;
> >
> > That's it.
> >
> > Ben.
>
> Thanks,
> Adam
>