| Message ID | 20241104172001.165640-1-herve.codina@bootlin.com |
|---|---|
| Headers | show |
| Series | Add support for the root PCI bus device-tree node creation. | expand |
On Mon, Nov 04, 2024 at 06:19:54PM +0100, Herve Codina wrote: > Hi, > > This series adds support for creating a device-tree node for a root PCI > bus on non device-tree based system. > > Creating device-tree nodes for PCI devices already exists upstream. It > was added in commit 407d1a51921e ("PCI: Create device tree node for > bridge"). Created device-tree nodes need a parent node to be attached > to. For the first level devices, on device-tree based system, this > parent node (i.e. the root PCI bus) is described in the base device-tree > (PCI controller). > > The LAN966x PCI device driver was recently accepted [1] and relies on > this feature. > > On system where the base hardware is not described by a device-tree, the > root PCI bus node to which first level created PCI devices need to be > attach to does not exist. This is the case for instance on ACPI > described systems such as x86. > > This series goal is to handle this case. > > In order to have the root PCI bus device-tree node available even on > x86, this top level node is created (if not already present) based on > information computed by the PCI core. It follows the same mechanism as > the one used for PCI devices device-tree node creation. > > In order to have this feature available, a number of changes are needed: > - Patch 1 and 2: Introduce and use device_{add,remove}_of_node(). > This function will also be used in the root PCI bus node creation. > > - Patch 3 and 4: Improve existing functions to reuse them in the root > PCI bus node creation. > > - Patch 5: Update the default value used when #address-cells is not > available in the device-tree root node. > > - Patch 6: The root PCI bus device-tree node creation itself. > > With those modifications, the LAN966x PCI device is working on x86 systems. That's nice, but I don't have a LAN966x device nor do I want one. We already have the QEMU PCI test device working with the existing PCI support. Please ensure this series works with it as well. Rob
Hi Rob, On Mon, 4 Nov 2024 14:15:07 -0600 Rob Herring <robh@kernel.org> wrote: ... > > With those modifications, the LAN966x PCI device is working on x86 systems. > > That's nice, but I don't have a LAN966x device nor do I want one. We > already have the QEMU PCI test device working with the existing PCI > support. Please ensure this series works with it as well. > I will check. Can you confirm that you are talking about this test: https://elixir.bootlin.com/linux/v6.12-rc6/source/drivers/of/unittest.c#L4188 The test needs QEMU with a specific setup and I found this entry point: https://lore.kernel.org/all/fa208013-7bf8-80fc-2732-814f380cebf9@amd.com/ Do you have an "official" QEMU setup on your side to run the test or any other pointers related to the QEMU command/setup you use? Best regards, Hervé
On Tue, Nov 5, 2024 at 11:44 AM Herve Codina <herve.codina@bootlin.com> wrote: > > Hi Rob, > > On Mon, 4 Nov 2024 14:15:07 -0600 > Rob Herring <robh@kernel.org> wrote: > > ... > > > With those modifications, the LAN966x PCI device is working on x86 systems. > > > > That's nice, but I don't have a LAN966x device nor do I want one. We > > already have the QEMU PCI test device working with the existing PCI > > support. Please ensure this series works with it as well. > > > > I will check. > > Can you confirm that you are talking about this test: > https://elixir.bootlin.com/linux/v6.12-rc6/source/drivers/of/unittest.c#L4188 > > The test needs QEMU with a specific setup and I found this entry point: > https://lore.kernel.org/all/fa208013-7bf8-80fc-2732-814f380cebf9@amd.com/ Yes, that's it. > Do you have an "official" QEMU setup on your side to run the test or any > other pointers related to the QEMU command/setup you use? No, it's just something based on what you linked. Here's what I have: qemu-system-aarch64 -machine virt -cpu cortex-a72 -machine type=virt -nographic -smp 1 -m 2048 -kernel ../linux.git/arch/arm64/boot/Image --append console=ttyAMA0 -device pcie-root-port,port=0x10,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x3 -device pcie-root-port,port=0x11,chassis=10,id=pci.10,bus=pcie.0,addr=0x3.0x1 -device x3130-upstream,id=pci.11,bus=pci.9,addr=0x0 -device xio3130-downstream,port=0x0,chassis=11,id=pci.12,bus=pci.11,multifunction=on,addr=0x0 -device i82801b11-bridge,id=pci.13,bus=pcie.0,addr=0x4 -device pci-bridge,chassis_nr=14,id=pci.14,bus=pci.13,addr=0x0 -device pci-testdev,bus=pci.12,addr=0x0 Of course, you'll need a few changes to use ACPI. Rob
Hi Rob, On Tue, 5 Nov 2024 13:59:40 -0600 Rob Herring <robh@kernel.org> wrote: > On Tue, Nov 5, 2024 at 11:44 AM Herve Codina <herve.codina@bootlin.com> wrote: > > > > Hi Rob, > > > > On Mon, 4 Nov 2024 14:15:07 -0600 > > Rob Herring <robh@kernel.org> wrote: > > > > ... > > > > With those modifications, the LAN966x PCI device is working on x86 systems. > > > > > > That's nice, but I don't have a LAN966x device nor do I want one. We > > > already have the QEMU PCI test device working with the existing PCI > > > support. Please ensure this series works with it as well. > > > > > > > I will check. > > > > Can you confirm that you are talking about this test: > > https://elixir.bootlin.com/linux/v6.12-rc6/source/drivers/of/unittest.c#L4188 > > > > The test needs QEMU with a specific setup and I found this entry point: > > https://lore.kernel.org/all/fa208013-7bf8-80fc-2732-814f380cebf9@amd.com/ > > Yes, that's it. > > > Do you have an "official" QEMU setup on your side to run the test or any > > other pointers related to the QEMU command/setup you use? > > No, it's just something based on what you linked. Here's what I have: > > qemu-system-aarch64 -machine virt -cpu cortex-a72 -machine type=virt > -nographic -smp 1 -m 2048 -kernel ../linux.git/arch/arm64/boot/Image > --append console=ttyAMA0 -device > pcie-root-port,port=0x10,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x3 > -device pcie-root-port,port=0x11,chassis=10,id=pci.10,bus=pcie.0,addr=0x3.0x1 > -device x3130-upstream,id=pci.11,bus=pci.9,addr=0x0 -device > xio3130-downstream,port=0x0,chassis=11,id=pci.12,bus=pci.11,multifunction=on,addr=0x0 > -device i82801b11-bridge,id=pci.13,bus=pcie.0,addr=0x4 -device > pci-bridge,chassis_nr=14,id=pci.14,bus=pci.13,addr=0x0 -device > pci-testdev,bus=pci.12,addr=0x0 > > Of course, you'll need a few changes to use ACPI. > I ran the OF kunit tests with the following command: qemu-system-x86_64 -machine q35 -nographic \ -kernel arch/x86_64/boot/bzImage --append console=ttyS0 \ -device pcie-root-port,port=0x10,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x3 \ -device pcie-root-port,port=0x11,chassis=10,id=pci.10,bus=pcie.0,addr=0x3.0x1 \ -device x3130-upstream,id=pci.11,bus=pci.9,addr=0x0 \ -device xio3130-downstream,port=0x0,chassis=11,id=pci.12,bus=pci.11,multifunction=on,addr=0x0 \ -device i82801b11-bridge,id=pci.13,bus=pcie.0,addr=0x4 \ -device pci-bridge,chassis_nr=14,id=pci.14,bus=pci.13,addr=0x0 \ -device pci-testdev,bus=pci.12,addr=0x0 Same -device options as the ones present in your command. Tests are successful: [ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 ... [ 0.030500] ACPI: Early table checksum verification disabled [ 0.030771] ACPI: RSDP 0x00000000000F5250 000014 (v00 BOCHS ) [ 0.030993] ACPI: RSDT 0x0000000007FE4068 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) [ 0.031438] ACPI: FACP 0x0000000007FE3E60 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) [ 0.031920] ACPI: DSDT 0x0000000007FE0040 003E20 (v01 BOCHS BXPC 00000001 BXPC 00000001) [ 0.031993] ACPI: FACS 0x0000000007FE0000 000040 [ 0.032036] ACPI: APIC 0x0000000007FE3F54 000078 (v03 BOCHS BXPC 00000001 BXPC 00000001) [ 0.032060] ACPI: HPET 0x0000000007FE3FCC 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) [ 0.032084] ACPI: MCFG 0x0000000007FE4004 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) [ 0.032105] ACPI: WAET 0x0000000007FE4040 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) [ 0.032171] ACPI: Reserving FACP table memory at [mem 0x7fe3e60-0x7fe3f53] [ 0.032206] ACPI: Reserving DSDT table memory at [mem 0x7fe0040-0x7fe3e5f] [ 0.032215] ACPI: Reserving FACS table memory at [mem 0x7fe0000-0x7fe003f] [ 0.032220] ACPI: Reserving APIC table memory at [mem 0x7fe3f54-0x7fe3fcb] [ 0.032226] ACPI: Reserving HPET table memory at [mem 0x7fe3fcc-0x7fe4003] [ 0.032231] ACPI: Reserving MCFG table memory at [mem 0x7fe4004-0x7fe403f] [ 0.032236] ACPI: Reserving WAET table memory at [mem 0x7fe4040-0x7fe4067] ... [ 3.466693] ### dt-test ### pass of_unittest_pci_node():4202 [ 3.466887] ### dt-test ### pass of_unittest_pci_node_verify():4155 [ 3.467133] ### dt-test ### pass of_unittest_pci_node_verify():4162 [ 3.467278] ### dt-test ### pass of_unittest_pci_node_verify():4169 [ 3.467442] ### dt-test ### pass of_unittest_pci_node():4214 [ 3.467572] ### dt-test ### pass of_unittest_pci_node():4216 [ 3.469993] ### dt-test ### pass of_unittest_pci_node_verify():4155 [ 3.470273] ### dt-test ### pass of_unittest_pci_node_verify():4175 [ 3.470577] ### dt-test ### pass of_unittest_pci_node_verify():4177 ... [ 3.513309] ### dt-test ### end of unittest - 387 passed, 0 failed Best regards, Hervé
Hi, This series adds support for creating a device-tree node for a root PCI bus on non device-tree based system. Creating device-tree nodes for PCI devices already exists upstream. It was added in commit 407d1a51921e ("PCI: Create device tree node for bridge"). Created device-tree nodes need a parent node to be attached to. For the first level devices, on device-tree based system, this parent node (i.e. the root PCI bus) is described in the base device-tree (PCI controller). The LAN966x PCI device driver was recently accepted [1] and relies on this feature. On system where the base hardware is not described by a device-tree, the root PCI bus node to which first level created PCI devices need to be attach to does not exist. This is the case for instance on ACPI described systems such as x86. This series goal is to handle this case. In order to have the root PCI bus device-tree node available even on x86, this top level node is created (if not already present) based on information computed by the PCI core. It follows the same mechanism as the one used for PCI devices device-tree node creation. In order to have this feature available, a number of changes are needed: - Patch 1 and 2: Introduce and use device_{add,remove}_of_node(). This function will also be used in the root PCI bus node creation. - Patch 3 and 4: Improve existing functions to reuse them in the root PCI bus node creation. - Patch 5: Update the default value used when #address-cells is not available in the device-tree root node. - Patch 6: The root PCI bus device-tree node creation itself. With those modifications, the LAN966x PCI device is working on x86 systems. [1] https://lore.kernel.org/lkml/7512cbb7911b8395d926e9e9e390fbb55ce3aea9.camel@pengutronix.de/ Best regards, Hervé Codina Herve Codina (6): driver core: Introduce device_{add,remove}_of_node() PCI: of: Use device_{add,remove}_of_node() to attach of_node to existing device PCI: of_property: Add support for NULL pdev in of_pci_set_address() PCI: of_property: Constify parameter in of_pci_get_addr_flags() of: Use the standards compliant default address cells value for x86 PCI: of: Create device-tree root bus node drivers/base/core.c | 52 ++++++++++++++++++ drivers/of/of_private.h | 2 +- drivers/pci/of.c | 89 +++++++++++++++++++++++++++++- drivers/pci/of_property.c | 113 ++++++++++++++++++++++++++++++++++++-- drivers/pci/pci.h | 6 ++ drivers/pci/probe.c | 2 + drivers/pci/remove.c | 2 + include/linux/device.h | 2 + 8 files changed, 260 insertions(+), 8 deletions(-)