Le mer. 28 nov. 2018 à 00:42, Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> a écrit : > > Date: Tue, 27 Nov 2018 21:14:04 +0000 > > From: Robert Swindells <r...@fdy2.co.uk> > > > > It looks to me that drivers try MSI and/or MSIX first based on the > > device type not on whether the host controller can handle it.
pci_intr_alloc() checks what the device claims to support down the call stack, reading the PCI config space. I assume there some negotiation between the PCI bus and the device. I hope device can't claim to support e.g. MSI-X if the bus doesn't. > Can we make the same API work for MSI, MSI-X, and INTx interrupts, so > that we don't have to remember two or three different APIs? Maybe > just pass a subset of PCI_INTR_INTx|PCI_INTR_MSI|PCI_INTR_MSIX to say > which ones to try or something? Yes, it would be the goal to have some shared API to do this fallback logic. But I need to understand whether it's actually necessary. It would be much simpler if we can rely on establish to work regardless of type of interrupt. Especially in 1/1/1 case, I don't see in the code a path where it would be possible for MSI/MSI-X establish to fail, but e.g. INTx one to not fail too. For sure, the MD allocation can fail due to some memory shortage or because we run out of interrupts, supported by the port. I don't see how establishing 1 MSI/MSI-X interrupt could fail, but then establishing 1 INTx could succeed. So perhaps it's okay to just to try to establish once and remove all those fallbacks. Unless the driver does something fancy, like try to use ncpu MSI interrupts and falling back to 1 INTx interrupt. I'd be in favour of simplifying the code to do just that in xhci(4) and ahcisata(4) - opinions? Jaromir
