On 11/07/16 11:51, Bharat Kumar Gogada wrote: >>> Hi Marc, >>> >>> Thanks for the reply. >>> >>> From PCIe Spec: >>> MSI Enable Bit: >>> 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. >>> >>> From Endpoint perspective, MSI Enable = 1 indicates MSI can be used >> which means MSI address and data fields are available/programmed. >>> >>> In our SoC whenever MSI Enable goes from 0 --> 1 the hardware latches >> onto MSI address and MSI data values. >>> >>> With current MSI implementation in kernel, our SoC is latching on to >> incorrect address and data values, as address/data >>> are updated much later than MSI Enable bit. >> >> Interesting. It looks like we're doing something wrong in the MSI flow. >> Can you confirm that this is limited to MSI and doesn't affect MSI-X? >> > I think it's the same issue irrespective of MSI or MSI-X as we are > enabling these interrupts before providing the vectors. > > So we always have a hole when MSI/MSI-X is 1, and software driver has > not registered the irq, and End Point may raise an interrupt (may be > due to error) in this point of time. Looking at the MSI-X part of the code, there is this: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/msi.c#n764 which hints that it may not be possible to do otherwise. Damned if you do, damned if you don't. M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
