From: David Vrabel <david.vrabel@csr.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: PCI: MSI interrupts masked using prohibited method
Date: Fri, 18 Jul 2008 11:33:10 +0100 [thread overview]
Message-ID: <48807166.9010006@csr.com> (raw)
In-Reply-To: <20080717194846.GU25255@parisc-linux.org>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
Matthew Wilcox wrote:
>
> I think David's original patch (just declining to mask the interrupt)
> is the best approach to take. Perhaps architectures with saner
> interrupt hardware would like to try the approach I've mentioned here.
>
> I don't like the comment in http://lkml.org/lkml/2008/6/27/199 as it's
> not prohibited ... just a bad idea. How about this patch?
The PCI specification is quite clear that it's prohibited. The problem
also is more severe than simply having spurious interrupts -- with some
devices if a line interrupt is generated (regardless of whether it ends
up on the bus) then no more interrupts are generated.
I also think that the change requires a comment in the code. It odd to
have a mask function that doesn't really mask so a comment is necessary
to explain why this is.
Please apply this instead.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pci-dont-mask-msi-with-msi-enable-bit.patch --]
[-- Type: text/x-diff; name="pci-dont-mask-msi-with-msi-enable-bit.patch", Size: 2272 bytes --]
PCI: don't mask MSIs with MSI Enable bit
Trying to mask MSIs with the MSI Enable results in some devices
generating a line interrupt (which may not appear on the bus if the
INTX# Disable bit is set). This interrupt will be lost and some
devices will generate no further interrupts (even after MSI Enable is
set again).
The PCI Local Bus Specification Revision 3.0, section 6.8.1.3. Message
Control for MSI on page 236, prohibits the use of the MSI Enable bit for
masking and unmasking the interrupt.
"MSI Enable: If 1 and the MSI-X Enable bit in the MSI-X Message
Control register (see Section 6.8.2.3) is 0, the
function is permitted to use MSI to request service
and is prohibited from using its INTx# pin (if
implemented; see Section 6.2.4 Interrupt pin register).
System configuration software sets this bit to enable
MSI. A device driver is prohibited from writing this bit
to mask a function’s service request."
There is no alternative method for mask/unmask on PCI devices with MSI
and no specific mask bit. In this case, the device driver will have
to ensure that MSIs are only generated when the device driver can
handle them (via some hardware specific mechanism such as
acknowledging the interrupt at the end of the interrupt handler) .
Signed-off-by: David Vrabel <david.vrabel@csr.com>
---
drivers/pci/msi.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
Index: linux-2.6-working/drivers/pci/msi.c
===================================================================
--- linux-2.6-working.orig/drivers/pci/msi.c 2008-06-27 12:24:17.000000000 +0100
+++ linux-2.6-working/drivers/pci/msi.c 2008-06-27 12:25:05.000000000 +0100
@@ -141,7 +141,18 @@
mask_bits |= flag & mask;
pci_write_config_dword(entry->dev, pos, mask_bits);
} else {
- msi_set_enable(entry->dev, !flag);
+ /*
+ * If there is no mask bit, this irq cannot be
+ * masked and the driver will have to use
+ * whatever hardware specific mechanisms are
+ * available to control the sending of MSI
+ * messages.
+ *
+ * Note: cannot attempt to mask via the MSI
+ * enable bit as that is prohibited by the PCI
+ * specification.
+ */
+ return;
}
break;
case PCI_CAP_ID_MSIX:
next prev parent reply other threads:[~2008-07-18 10:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-24 10:46 PCI: MSI interrupts masked using prohibited method David Vrabel
2008-06-25 21:20 ` Jesse Barnes
2008-06-27 12:17 ` David Vrabel
2008-06-27 17:07 ` Jesse Barnes
2008-07-16 19:43 ` Jesse Barnes
2008-07-16 19:58 ` Matthew Wilcox
2008-07-16 20:35 ` David Miller
2008-07-17 12:16 ` Krzysztof Halasa
2008-07-17 12:43 ` Matthew Wilcox
2008-07-17 13:14 ` David Vrabel
2008-07-17 15:39 ` Matthew Wilcox
2008-07-17 15:58 ` Thomas Gleixner
2008-07-17 16:11 ` Matthew Wilcox
2008-07-17 17:04 ` Thomas Gleixner
2008-07-17 16:56 ` Matthew Wilcox
[not found] ` <487F7DFA.10101@csr.com>
2008-07-17 19:48 ` Matthew Wilcox
2008-07-18 10:33 ` David Vrabel [this message]
2008-07-22 13:56 ` Michal Schmidt
2008-07-22 17:52 ` Jesse Barnes
2008-07-23 13:02 ` Michal Schmidt
2008-07-25 13:29 ` Michal Schmidt
2008-07-25 13:42 ` Matthew Wilcox
2008-07-25 13:53 ` Michal Schmidt
2008-07-25 15:51 ` Matthew Wilcox
2008-07-28 9:54 ` Michal Schmidt
2008-07-25 16:37 ` David Vrabel
2008-07-25 16:56 ` Matthew Wilcox
2008-07-25 19:12 ` Jesse Barnes
2008-07-28 9:59 ` Michal Schmidt
2008-07-28 22:04 ` Jesse Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48807166.9010006@csr.com \
--to=david.vrabel@csr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew@wil.cx \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox