On 03.08.2018 21:40, Thomas Gleixner wrote: > On Fri, 3 Aug 2018, Heiner Kallweit wrote: >> On 03.08.2018 16:09, Thomas Gleixner wrote: >>> On Wed, 1 Aug 2018, Heiner Kallweit wrote: >>>> diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c >>>> index 4ca2fd46..ba6da943 100644 >>>> --- a/kernel/irq/msi.c >>>> +++ b/kernel/irq/msi.c >>>> @@ -289,6 +289,9 @@ struct irq_domain *msi_create_irq_domain(struct fwnode_handle *fwnode, >>>> if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS) >>>> msi_domain_update_chip_ops(info); >>>> >>>> + /* MSI is oneshot-safe in general */ >>>> + info->chip->flags |= IRQCHIP_ONESHOT_SAFE; >>>> + >>>> domain = irq_domain_create_hierarchy(parent, IRQ_DOMAIN_FLAG_MSI, 0, >>> >>> Looks about right, though there might be dragons. MSI is not always as sane >>> as it should be... >>> >> When saying "MSI isn't always sane", are you referring to the hardware or >> the controller driver implementation? Basically for me the question is >> whether we would be able to fix the issue if we meet such a dragon, >> or whether we would have to revert the change. > > It's hardware unfortunately, so it might be a revert. PCI-MSI should be > safe, but the wild MSI variants in SoCs might be the actual dragon caves. > pci_msi_create_irq_domain() is used by controller drivers for PCI(e) controllers in SoCs like Mediatek, Armada, .. I assume you're referring to some other (non-PCI) SoC-internal MSI mechanism when saying "wild variants", right? >> Do you think the chance of a dragon is low enough? Or better add the >> flag only to the X86 PCI MSI irqchip for now? > > I think PCI-MSI in general would be not too risky. Famous last words. > > Thanks, > > tglx >
