On Mon, 25 Jul 2016, Bjorn Helgaas wrote:
> On Mon, Jul 25, 2016 at 09:45:13AM +0200, Thomas Gleixner wrote:
> I thought the original issue [1] was that PCI_MSI_FLAGS_ENABLE was being
> written before PCI_MSI_ADDRESS_LO.  That doesn't sound like a good
> idea to me.

Well. That's only a problem if the PCI device does not support masking. But
yes, we missed that case back then.
 
> That does seem like a problem.  Maybe it would be better to delay
> setting PCI_MSI_FLAGS_ENABLE until after the MSI address & data bits
> have been set?

I thought about that, but that gets ugly pretty fast. Here is an alternative
solution.

I think that's the proper place to do it _AFTER_ the hierarchical allocation
took place. On x86 Marc's ACTIVATE_EARLY flag would not work because the
message is not yet ready to be assembled.

Thanks,

        tglx
---
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index a080f4496fe2..142341f8331b 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -645,6 +645,15 @@ static int msi_capability_init(struct pci_dev *dev, int 
nvec)
                return ret;
        }
 
+       /*
+        * The mask can be ignored and PCI 2.3 does not specify mask bits for
+        * each MSI interrupt. So in case of hierarchical irqdomains we need
+        * to make sure that if masking is not available that the msi message
+        * is written prior to setting the MSI enable bit in the device.
+        */
+       if (pci_msi_ignore_mask || !entry->msi_attrib.maskbit)
+               irq_domain_activate_irq(irq_get_irq_data(entry->irq));
+
        /* Set MSI enabled bits  */
        pci_intx_for_msi(dev, 0);
        pci_msi_set_enable(dev, 1);

Reply via email to