On Fri, 30 Nov 2018, Martin Husemann wrote:
On Fri, Nov 30, 2018 at 02:22:37PM -0400, Jared McNeill wrote:
The driver can call pci_intr_type on the handle returned by pci_intr_alloc
to see what kind of interrupt (INTx/MSI/MSI-X) was negotiated.
Yeah, but the fear was that some hardware could either do a single INT
or (lots of) MSI{X}, and now you end up with (lots of) INT returned
from pci_intr_alloc() and can just use the first.
Does this not happen for real world hardware, or is the driver supposed to
check with pci_*_count() upfront?
I don't think pci_intr_alloc will ever return more than one INTx..
[ 1.0426355] ahcisata0 at pci0 dev 19 function 0: vendor 8086 product 19b2 (rev. 0x10)
[ 1.0426355] allocated pic msix5 type edge pin 0 level 6 to cpu0 slot 21 idt entry 110
[ 1.0426355] ahcisata0: interrupting at msix5 vec 0
[ 1.0426355] ahcisata0: 64-bit DMA
[ 1.0426355] ahcisata0: AHCI revision 1.31, 1 port, 32 slots, CAP 0xc3369f40<EMS,PMD,SPM,SAM,ISS=0x3=Gen3,SCLO,SAL,SNCQ,S64A>
[ 1.0426355] atabus0 at ahcisata0 channel 3
[ 1.0426355] ahcisata1 at pci0 dev 20 function 0: vendor 8086 product 19c2 (rev. 0x10)
[ 1.0426355] allocated pic msix6 type edge pin 0 level 6 to cpu0 slot 22 idt entry 111
[ 1.0426355] ahcisata1: interrupting at msix6 vec 0
[ 1.0426355] ahcisata1: 64-bit DMA
[ 1.0426355] ahcisata1: AHCI revision 1.31, 2 ports, 32 slots, CAP 0xc3369f41<EMS,PMD,SPM,SAM,ISS=0x3=Gen3,SCLO,SAL,SNCQ,S64A>
[ 1.0426355] atabus1 at ahcisata1 channel 4
[ 1.0426355] atabus2 at ahcisata1 channel 5
(snip)
[ 3.4536958] wd0 at atabus2 drive 0
[ 6.4561682] wd0: IDENTIFY failed
[ 6.4561682] wd0: fixing 0 sector size
[ 6.4561682] wd0: secperunit and ncylinders are zero
[ 9.4686496] wd0(ahcisata1:5:0): using PIO mode 0
(snip)
[ 9.6688146] boot device: <unknown>