> IRQF_DISABLED is a NOOP now, place where suggest to use this > flag also doesn't make sense any more. > > Signed-off-by: Yong Zhang <yong.zhang0@xxxxxxxxx> > --- > Documentation/PCI/MSI-HOWTO.txt | 21 --------------------- > Documentation/scsi/ncr53c8xx.txt | 4 +++- > Documentation/scsi/tmscsim.txt | 4 ++-- > 3 files changed, 5 insertions(+), 24 deletions(-) > > diff --git a/Documentation/PCI/MSI-HOWTO.txt > b/Documentation/PCI/MSI-HOWTO.txt > index 53e6fca..b3f514d 100644 > --- a/Documentation/PCI/MSI-HOWTO.txt > +++ b/Documentation/PCI/MSI-HOWTO.txt > @@ -255,27 +255,6 @@ as many vectors for MSI as it could for MSI-X. On > some platforms, MSI > interrupts must all be targeted at the same set of CPUs whereas MSI-X > interrupts can all be targeted at different CPUs. > > -4.5.2 Spinlocks > - > -Most device drivers have a per-device spinlock which is taken in the > -interrupt handler. With pin-based interrupts or a single MSI, it is not > -necessary to disable interrupts (Linux guarantees the same interrupt will > -not be re-entered). If a device uses multiple interrupts, the driver > -must disable interrupts while the lock is held. If the device sends > -a different interrupt, the driver will deadlock trying to recursively > -acquire the spinlock. > - > -There are two solutions. The first is to take the lock with > -spin_lock_irqsave() or spin_lock_irq() (see > -Documentation/DocBook/kernel-locking). The second is to specify > -IRQF_DISABLED to request_irq() so that the kernel runs the entire > -interrupt routine with interrupts disabled. > - > -If your MSI interrupt routine does not hold the lock for the whole time > -it is running, the first solution may be best. The second solution is > -normally preferred as it avoids making two transitions from interrupt > -disabled to enabled and back again. Is this whole section really obsolete now? Or is it only the part that suggests IRQF_DISABLED? Eike -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
