[PATCH 54/57] Documentation: irq: Change documents related to IRQF_DISABLED
From: Yong Zhang <hidden>
Date: 2011-09-21 09:36:49
Also in:
lkml
Subsystem:
documentation, pci subsystem, the rest · Maintainers:
Jonathan Corbet, Bjorn Helgaas, Linus Torvalds
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 <redacted> --- 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. - 4.6 How to tell whether MSI/MSI-X is enabled on a device Using 'lspci -v' (as root) may show some devices with "MSI", "Message
diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt
index cda5f8f..c5a9904 100644
--- a/Documentation/scsi/ncr53c8xx.txt
+++ b/Documentation/scsi/ncr53c8xx.txt@@ -786,7 +786,9 @@ port address 0x1400. irqm:1 same as initial settings (assumed BIOS settings) irqm:2 always totem pole irqm:0x10 driver will not use IRQF_SHARED flag when requesting irq - irqm:0x20 driver will not use IRQF_DISABLED flag when requesting irq + irqm:0x20 driver will not use IRQF_DISABLED (does not make sense + any more since genirq will keep irq disabled and the flag + is dead from linux-2.6.35) flag when requesting irq (Bits 0x10 and 0x20 can be combined with hardware irq mode option)
diff --git a/Documentation/scsi/tmscsim.txt b/Documentation/scsi/tmscsim.txt
index 61c0531..1dee219 100644
--- a/Documentation/scsi/tmscsim.txt
+++ b/Documentation/scsi/tmscsim.txt@@ -108,8 +108,8 @@ MHz PCI bus works for me, though, but I don't recommend using higher clocks than the 33.33 MHz being in the PCI spec. If you want to share the IRQ with another device and the driver refuses to -do so, you might succeed with changing the DC390_IRQ type in tmscsim.c to -IRQF_SHARED | IRQF_DISABLED. +do so, you should find out what's the mismatch between the shared IRQs, +and CONFIG_DEBUG_SHIRQ may give you more help. 3.Features
--
1.7.4.1