On Wed, Jun 20, 2018 at 05:42:51PM -0400, Sinan Kaya wrote: > On 6/20/2018 5:38 PM, Keith Busch wrote: > > Now that the DPC driver clears the interrupt status before exiting the > > irq handler, we don't need to abuse the DPC control register to know if > > a shared interrupt is for a new DPC event: a DPC port can not trigger > > a second interrupt until the host clears the trigger status later in the > > work queue handler. > > > > Signed-off-by: Keith Busch <keith.busch@xxxxxxxxx> > > Isn't this a problem with legacy interrupts on the root ports with no MSI? > (can be tested with pci=nomsi) > > DPC interrupt handler gets called for all service driver interrupts like AER, PME and > HP. According to PCIe spec, the DPC level-triggered interrupt requires these: The Interrupt Disable bit in Comand register is 0b The value of DPC Interrupt Enable bit is 1b The value of the DPC Interrupt Status bit is 1b We now clear DPC Interrupt Status bit prior to exiting the IRQ handler, so that should satisfy clearing INTx messages, making the DPC Interrupt Enable control toggling redundant. We weren't doing that before, so this would have been a problem back then. If a shared interrupt occurs for another service (say, AER) before DPC's bottom half handler runs, the DPC Interrupt Status won't be set, so the DPC driver will return IRQ_NONE.
