| 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
| ||
|
Message-ID: <20250617090029.03283ea6@bootlin.com> Date: Tue, 17 Jun 2025 09:00:29 +0200 From: Herve Codina <herve.codina@...tlin.com> To: Claudiu Beznea <claudiu.beznea@...on.dev> Cc: "robh+dt@...nel.org" <robh+dt@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>, Danilo Krummrich <dakr@...nel.org>, Saravana Kannan <saravanak@...gle.com>, Bjorn Helgaas <bhelgaas@...gle.com>, Lizhi Hou <lizhi.hou@....com>, linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, linux-pci@...r.kernel.org, Allan Nielsen <allan.nielsen@...rochip.com>, Horatiu Vultur <horatiu.vultur@...rochip.com>, Steen Hegelund <steen.hegelund@...rochip.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com> Subject: Re: [PATCH v8 5/5] PCI: of: Create device-tree PCI host bridge node Hi Claudiu, On Fri, 13 Jun 2025 16:36:16 +0300 Claudiu Beznea <claudiu.beznea@...on.dev> wrote: ... > I pointed to the wrong function. It's not of_pci_make_host_bridge_node() > [1] but of_pci_make_dev_node() which creates a node with a similar naming > and makes things not working on my side. > > [1] https://elixir.bootlin.com/linux/v6.15/source/drivers/pci/of.c#L694 Ok, so your issue is not related patches applied from the "PCI: of: Create device-tree PCI host bridge node" series. https://lore.kernel.org/all/20250224141356.36325-6-herve.codina@bootlin.com/ Indeed, this series add the node creation for the host bridge with of_pci_make_host_bridge_node() but you pointed now of_pci_make_dev_node() which is the creation for PCI device node and this function was not modify by the series. of_pci_make_host_bridge_node() should not create anything. Can you confirm on your side that it doesn't create any nodes. If so, maybe the problem comes from of_irq_parse_raw() or similar. ... > > > > > On this system, I didn't observed any issues but of course, the PCIe drivers are > > different. > > Also, on my system, no node were created by of_pci_make_host_bridge_node(). > > Sorry for the confusion, it is of_pci_make_dev_node() on my side which > creates the node. > > > > > To be honest, I didn't re-test recently to see if something has been broken. > > I can do that on my side with my system. I have re-tested and I confirm that I have no issue on my system. > > > > On your side, maybe you can have look at the Armada PCIe driver and see if > > something could explain your behavior. I am not sure that you need to add the > > pci@0,0 node in your DT. > > I can't find a driver that uses the approach I'm trying in my patches. This > approach was suggested in the review process [2] by Rob who mentioned that > now we should be able drop legacy interrupt controller nodes. There are > some Apple device trees that points the interrupt-map to the port node (the > way I tried in my workaround) [3], but I can't find more than that. > > The topology in my case is: > > root@...rc-rzg3s:~# lspci -t > -[0000:00]---00.0-[01]----00.0 > > root@...rc-rzg3s:~# lspci > 00:00.0 PCI bridge: Renesas Technology Corp. Device 0033 > 01:00.0 Non-Volatile memory controller: Micron Technology Inc 2550 NVMe SSD > (DRAM-less) (rev 01) > > When not working pci@0,0 is exported as follows in rootfs: > > root@...rc-rzg3s:~# ls /sys/firmware/devicetree/base/soc/pcie@...40000 -l > -r--r--r-- 1 root root 4 Jan 12 10:28 #address-cells > -r--r--r-- 1 root root 4 Jan 12 10:28 #interrupt-cells > -r--r--r-- 1 root root 4 Jan 12 10:28 #size-cells > -r--r--r-- 1 root root 8 Jan 12 10:28 bus-range > -r--r--r-- 1 root root 13 Jan 12 10:28 clock-names > -r--r--r-- 1 root root 24 Jan 12 10:28 clocks > -r--r--r-- 1 root root 26 Jan 12 10:28 compatible > -r--r--r-- 1 root root 4 Jan 12 10:28 device-id > -r--r--r-- 1 root root 4 Jan 12 10:28 device_type > -r--r--r-- 1 root root 28 Jan 12 10:28 dma-ranges > -r--r--r-- 1 root root 0 Jan 12 10:28 interrupt-controller > -r--r--r-- 1 root root 144 Jan 12 10:28 interrupt-map > -r--r--r-- 1 root root 16 Jan 12 10:28 interrupt-map-mask > -r--r--r-- 1 root root 164 Jan 12 10:28 interrupt-names > -r--r--r-- 1 root root 4 Jan 12 10:28 interrupt-parrent Why parrent instead of parent in interrupt-parrent ? > -r--r--r-- 1 root root 192 Jan 12 10:28 interrupts > -r--r--r-- 1 root root 5 Jan 12 10:28 name > -r--r--r-- 1 root root 4 Jan 12 10:28 num-lanes > drwxr-xr-x 2 root root 0 Jan 12 10:17 pci@0,0 > -r--r--r-- 1 root root 4 Jan 12 10:28 phandle > -r--r--r-- 1 root root 4 Jan 12 10:28 pinctrl-0 > -r--r--r-- 1 root root 8 Jan 12 10:28 pinctrl-names > -r--r--r-- 1 root root 4 Jan 12 10:28 power-domains > -r--r--r-- 1 root root 28 Jan 12 10:28 ranges > -r--r--r-- 1 root root 16 Jan 12 10:28 reg > -r--r--r-- 1 root root 4 Jan 12 10:28 renesas,sysc > -r--r--r-- 1 root root 63 Jan 12 10:28 reset-names > -r--r--r-- 1 root root 56 Jan 12 10:28 resets > -r--r--r-- 1 root root 5 Jan 12 10:28 status > -r--r--r-- 1 root root 4 Jan 12 10:28 vendor-id > root@...rc-rzg3s:~# > root@...rc-rzg3s:~# ls > /sys/firmware/devicetree/base/soc/pcie@...40000/pci@0,0 -l > -r--r--r-- 1 root root 4 Jan 12 10:17 #address-cells > -r--r--r-- 1 root root 4 Jan 12 10:17 #interrupt-cells > -r--r--r-- 1 root root 4 Jan 12 10:17 #size-cells > -r--r--r-- 1 root root 8 Jan 12 10:17 bus-range > -r--r--r-- 1 root root 41 Jan 12 10:17 compatible > -r--r--r-- 1 root root 4 Jan 12 10:17 device_type > -r--r--r-- 1 root root 144 Jan 12 10:17 interrupt-map > -r--r--r-- 1 root root 16 Jan 12 10:17 interrupt-map-mask > -r--r--r-- 1 root root 32 Jan 12 10:17 ranges > -r--r--r-- 1 root root 20 Jan 12 10:17 reg > root@...rc-rzg3s:~# > root@...rc-rzg3s:~# > root@...rc-rzg3s:~# > root@...rc-rzg3s:~# > root@...rc-rzg3s:~# cat > /sys/firmware/devicetree/base/soc/pcie@...40000/pci@0,0/compatible > pci1912,33pciclass,060400pciclass,0604root@...rc-rzg3s:~# > root@...rc-rzg3s:~# > root@...rc-rzg3s:~# > > In case I describe a port in device tree, it works because the pci@0,0 is > not created anymore when device is enumerated and thus the interrupt > parsing is working. > > Herve: do you have some hints? First interrupt-parrent in your /sys/firmware/devicetree/base/soc/pcie@...40000 files. If it is just a typo in this email, maybe the interrupt parsing itself. Can you provide an extract for the DT with nodes created at runtime. I mean can you run 'dtc -I dtb -O dts /proc/device-tree' and provide the output related to PCI nodes including the PCIe controller ? > > Rob: do you know some device trees where the interrupt-map points to the > node itself as suggested in [2] so that I can check is something is missing > on my side? > > Thank you, > Claudiu > > [2] https://lore.kernel.org/all/20250509210800.GB4080349-robh@kernel.org/ > [3] > https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/apple/t8112.dtsi#L951 > Best regards, Hervé -- Hervé Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Powered by blists - more mailing lists