Hi, On 10/6/25 6:06 AM, Michael Kelly wrote: > Based on research (this PCI detail is admittedly new to me), I've seen > it described (https://f.osdev.org/viewtopic.php?t=29558) that to > identify the interrupt that is actually assigned to the device, it is > necessary to make a mapping between the device's interrupt pin > (discovered by PCI enumeration) and the possibilities listed within the > ACPI tables. In other words, one needs to identify whether INTA, INTB, > INTC or INTD is is the pin in use with pci device bus:dev:fun. Then > filter the entries in the _PRT to those matching the same pin. ie replace: > > if ((prt_dev == dev) && (prt_func == 0xffff)) > with > > if ((prt_dev == dev) && (prt_func == 0xffff) && entry->pin == > pci_dev_pin) > > The above strategy would return the correct 11 IRQ in my case. I'd like > to have coded this suggestion to make clear what I'm describing but I'm > still puzzling over the best method of reading the PCI configuration > space header to determine pci_dev_pin in the code fragment. I don't want > to waste my time if I'm horribly wrong. I've seen that on my machine, > Linux lspci -vvv shows INTB used. There are _PRS mappings that refer to > IRQ 10 in INTA which would be selected first by the existing code. > You may be onto something here: I didn't realise the INTx pins were predetermined per device.
In this case, yes, you will need to create a acpi_pci_id structure and call lookup_pci_dev(), then read out the "#define PCI_INTERRUPT_PIN 0x3d" from the device's config space and match as you have suggested above, I think. Well spotted. Damien
