> A little more qualification would be that: > write(...,device); // Disable int > wmb() > enable_ints(); > Is expected to have a potential spurious interrupt. But, perhaps this is > OK: > outl(...,device); > wmb(); > enable_ints(); > This is consistant with how the PCI spec discusses ordering/etc and > barriers are frequently used in the PCI drivers. Looking at the i386 code > this is what I would expect to see. > > Anyone know for sure? The x86 behaviour forced as I understand it is barrier() - compiler level store barrier rmb() - read barrier to bus/DMA level [no operation] wmb() - write barrier to bus/DMA level [synchronizing instruction sequence of locked add of 0 to stack top] (mb and wmb as names come from Alpha so I guess its definitive 8)) It does not enforce PCI posting. Also your spurious interrupt case is wrong for other horrible reasons. Interrupt delivery must never be assumed to be synchronous in a portable driver. (In fact you'll see async irq delivery on an X86)
