tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pci_intr_alloc() vs pci_intr_establish() - retry type?



Le mer. 28 nov. 2018 à 00:42, Taylor R Campbell
<campbell+netbsd-tech-kern%mumble.net@localhost> a écrit :
> > Date: Tue, 27 Nov 2018 21:14:04 +0000
> > From: Robert Swindells <rjs%fdy2.co.uk@localhost>
> >
> > 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


Home | Main Index | Thread Index | Old Index