linux-kernel - Re: [PATCH] PCI: mvebu: Use devm_request_irq() for registering interrupt handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250311162407.GA630741@bhelgaas>
Date: Tue, 11 Mar 2025 11:24:07 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Luís Mendes <luis.p.mendes@...il.com>
Cc: Marc Zyngier <maz@...nel.org>,
	Pali Rohár <pali@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Wilczyński <kw@...ux.com>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: mvebu: Use devm_request_irq() for registering
 interrupt handler

On Sun, Mar 09, 2025 at 11:10:58PM +0000, Luís Mendes wrote:
> All logs presented were obtained from a SolidRun A388 ClearFog Base,
> if more detailed PCI logs are needed I have the other machine, the
> Armada Duo that has 2 PCIe slots and handles an AMD RX 550 GPU. Just
> let me know.
> 
> - Complete dmesg log, booted with "pci=nomsi"  is available here:
> https://pastebin.com/wDj0NGFN
> - Complete output of "sudo lspci -vv" is available here:
> https://pastebin.com/f4yHRhLr
> - Contents of /proc/interrupts is available here: https://pastebin.com/ejDUuhbJ
> - Output of "grep -r . /proc/irq/" is available here:
> https://pastebin.com/4jvFBBhy

Thank you very much for these.

It looks like the only PCI device is 01:00.0: [1ac1:089a], a Coral
Edge TPU, and I don't see any evidence of a driver for it or any IRQ
usage.  Do you have any other PCI device you could try there?
Something with a driver that uses interrupts?

Not critical right now, but I'm puzzled by this part of the dmesg log:

  mvebu-pcie soc:pcie: host bridge /soc/pcie ranges:
  mvebu-pcie soc:pcie:      MEM 0x00f1080000..0x00f1081fff -> 0x0000080000
  mvebu-pcie soc:pcie:      MEM 0x00f1040000..0x00f1041fff -> 0x0000040000
  mvebu-pcie soc:pcie:      MEM 0x00f1044000..0x00f1045fff -> 0x0000044000
  mvebu-pcie soc:pcie:      MEM 0x00f1048000..0x00f1049fff -> 0x0000048000
  pci_bus 0000:00: root bus resource [mem 0xf1080000-0xf1081fff] (bus address [0x00080000-0x00081fff])
  pci_bus 0000:00: root bus resource [mem 0xf1040000-0xf1041fff] (bus address [0x00040000-0x00041fff])
  pci_bus 0000:00: root bus resource [mem 0xf1044000-0xf1045fff] (bus address [0x00044000-0x00045fff])
  pci_bus 0000:00: root bus resource [mem 0xf1048000-0xf1049fff] (bus address [0x00048000-0x00049fff])
  pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]

The first four mvebu-pcie lines make good sense and match the
first four pci_bus lines.  But I don't know where the
[mem 0xe0000000-0xe7ffffff] aperture came from.  It should be
described in the devicetree, but I don't see it mentioned in the
/soc/pcie ranges.

Can you include the devicetree as well?