Hi Sathyam,
On Thu, Nov 11, 2021 at 12:02:31PM +0000, Sathyam Panda wrote:
> The interrupt pin cell in "interrupt-map" property
> is defined only for legacy interrupts with a valid
> range in [1-4] corrspoding to INTA#..INTD#. And the
> PCI endpoint devices that support advance interrupt
> mechanism like MSI or MSI-X should not have an entry
> with value 0 in "interrupt-map". This patch takes
> care of this problem by avoiding redundant entries.
>
> Signed-off-by: Sathyam Panda <sathyam.panda@xxxxxxx>
> Reviewed-by: Vivek Kumar Gautam <vivek.gautam@xxxxxxx>
> ---
> arm/pci.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arm/pci.c b/arm/pci.c
> index 2251f62..e44e453 100644
> --- a/arm/pci.c
> +++ b/arm/pci.c
> @@ -80,6 +80,16 @@ void pci__generate_fdt_nodes(void *fdt)
> u8 irq = pci_hdr->irq_line;
> u32 irq_flags = pci_hdr->irq_type;
>
> + /*
> + * Avoid adding entries in "interrupt-map" for devices that
> + * will be using advance interrupt mechanisms like MSI or
> + * MSI-X instead of legacy interrupt pins INTA#..INTD#
> + */
> + if (pin == 0) {
> + dev_hdr = device__next_dev(dev_hdr);
> + continue;
> + }
I found this in "Open Firmware Recommended Practive: Interrupt Mapping" [1]
(referenced by Documentation/devicetree/bindings/pci/pci.txt in the Linux source
tree), in the PCI bus examples section (page 8):
"The PCI binding defines an "interrupts" property to consist of one cell, which
encodes wheth- er the PCI device’s interrupt is connected to the PCI connector’s
INTA#...INTD# pins, with values 1...4, respectively (assuming that the device is
on a plug-in PCI card)".
The patch makes sense to me, if the interrupt pin is not present a the device,
don't describe it in the DTB:
Reviewed-by: Alexandru Elisei <alexandru.elisei@xxxxxxx>
[1] https://www.devicetree.org/open-firmware/practice/imap/imap0_9d.pdf
Thanks,
Alex
> +
> *entry = (struct of_interrupt_map_entry) {
> .pci_irq_mask = {
> .pci_addr = {
> --
> 2.25.1
>
