Look at the implementation of "cli()" - when called from within a hardware
interrupt, it will do something else than what you think it's doing, and
"synchronize_irq()" will basically be a no-op.
> For curiosity I taken a look to the first two usages of synchronize_irq()
> that a recursive grep picked up in the device drivers directory.
>
> drivers/net/de4x5.c:
Bogus. It won't really harm (see no-op above), but it certainly doesn't
help either.
> Here from plip.c:
Again, that one looks like it shouldn't actually harm anything, but
doesn't help.
For the REAL uses, look at some of the SCSI and sound drivers:
outb(~0, s->ioenh + SV_CODEC_INTMASK); /* disable ints */
synchronize_irq();
where the point of synchronize_irq() is to just wait for current
interrupts to exit, because we just asked the card to not send any new
ones.
That's still not necessarily a good practice (see my previous email about
asynchroneity wrt CPU/device models), but at least it's not a silly no-op
like the ones you looked at.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/