On Mon, Jan 29, 2018 at 10:34:44PM -0800, poza@xxxxxxxxxxxxxx wrote: > On 2018-01-30 11:59, Oza Pawandeep wrote: > > + Oza > > > > On Tue, Jan 30, 2018 at 7:41 AM, Sinan Kaya <okaya@xxxxxxxxxxxxxx> > > wrote: > >> On 1/29/2018 4:31 PM, Keith Busch wrote: > >>> + if (!work_busy(&dpc->work)) > >>> + schedule_work(&dpc->work); > >> > >> Isn't there a race condition between the time that dpc_work() clears > >> PCI_EXP_DPC_STATUS > >> register and when work actually completes by returning from > >> dpc_work()? > >> > >> If the interrupt arrives just in this window, this code will not > >> schedule the work. > >> > >> -- > >> Sinan Kaya > >> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm > >> Technologies, Inc. > >> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a > >> Linux Foundation Collaborative Project. > > besides, there is one more problem which I was debugging: > if RP doesnt support MSI, then legacy interrupts are not well handled > and we get interrupt storm. > this is because; > PCI_EXP_DPC_STATUS_INTERRUPT is being cleared in deferred work. > which should get cleared in dpc_irq interrupt handler. Okay, thanks for that information. I haven't got a DPC capable device that supports INTx, so that's a gap in my current testing capabilities. It looks like as you're suggesting, we should clear DPC Interrupt Status in the top-half IRQ handler, and we should not see another DPC interrupt raised until after we clear DPC Trigger Status in the bottom-half.
