| Message ID | 20201022220038.1339854-1-robh@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | PCI: mvebu: Fix duplicate resource requests | expand |
On Thu, Oct 22, 2020 at 05:00:38PM -0500, Rob Herring wrote: > With commit 669cbc708122 ("PCI: Move DT resource setup into > devm_pci_alloc_host_bridge()"), the DT 'ranges' is parsed and populated > into resources when the host bridge is allocated. The resources are > requested as well, but that happens a 2nd time for the mvebu driver in > mvebu_pcie_parse_request_resources(). We should only be requesting the > additional resources added in mvebu_pcie_parse_request_resources(). > These are not added by default because the use custom properties rather > than standard DT address translation. > > Also, the bus ranges was also populated by default, so we can remove > it from mvebu_pci_host_probe(). Still doesn't work. mvebu-pcie soc:pcie: resource collision: [io 0x1000-0xeffff] conflicts with System RAM [mem 0x00000000-0x3fffffff] mvebu-pcie: probe of soc:pcie failed with error -16 > > Fixes: 669cbc708122 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()") > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209729 > Reported-by: vtolkm@googlemail.com > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> > Cc: Jason Cooper <jason@lakedaemon.net> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> > Cc: Bjorn Helgaas <bhelgaas@google.com> > Cc: Russell King <linux@armlinux.org.uk> > Cc: linux-pci@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > Untested, please test. > > drivers/pci/controller/pci-mvebu.c | 23 ++++++++++------------- > 1 file changed, 10 insertions(+), 13 deletions(-) > > diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c > index c39978b750ec..c6fc8bd5e77f 100644 > --- a/drivers/pci/controller/pci-mvebu.c > +++ b/drivers/pci/controller/pci-mvebu.c > @@ -960,25 +960,16 @@ static void mvebu_pcie_powerdown(struct mvebu_pcie_port *port) > } > > /* > - * We can't use devm_of_pci_get_host_bridge_resources() because we > - * need to parse our special DT properties encoding the MEM and IO > - * apertures. > + * devm_of_pci_get_host_bridge_resources() only sets up translateable resources, > + * so we need extra resource setup parsing our special DT properties encoding > + * the MEM and IO apertures. > */ > static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) > { > struct device *dev = &pcie->pdev->dev; > - struct device_node *np = dev->of_node; > struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie); > int ret; > > - /* Get the bus range */ > - ret = of_pci_parse_bus_range(np, &pcie->busn); > - if (ret) { > - dev_err(dev, "failed to parse bus-range property: %d\n", ret); > - return ret; > - } > - pci_add_resource(&bridge->windows, &pcie->busn); > - > /* Get the PCIe memory aperture */ > mvebu_mbus_get_pcie_mem_aperture(&pcie->mem); > if (resource_size(&pcie->mem) == 0) { > @@ -988,6 +979,9 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) > > pcie->mem.name = "PCI MEM"; > pci_add_resource(&bridge->windows, &pcie->mem); > + ret = devm_request_resource(dev, &iomem_resource, &pcie->mem); > + if (ret) > + return ret; > > /* Get the PCIe IO aperture */ > mvebu_mbus_get_pcie_io_aperture(&pcie->io); > @@ -1001,9 +995,12 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) > pcie->realio.name = "PCI I/O"; > > pci_add_resource(&bridge->windows, &pcie->realio); > + ret = devm_request_resource(dev, &iomem_resource, &pcie->realio); I think you're trying to claim this resource against the wrong parent. > + if (ret) > + return ret; > } > > - return devm_request_pci_bus_resources(dev, &bridge->windows); > + return 0; > } > > /* > -- > 2.25.1 > >
On Thu, Oct 22, 2020 at 11:05:07PM +0100, Russell King - ARM Linux admin wrote: > > @@ -1001,9 +995,12 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) > > pcie->realio.name = "PCI I/O"; > > > > pci_add_resource(&bridge->windows, &pcie->realio); > > + ret = devm_request_resource(dev, &iomem_resource, &pcie->realio); > > I think you're trying to claim this resource against the wrong parent. Fixing this to ioport_resource results in in working PCIe.
On Thu, Oct 22, 2020 at 5:09 PM Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > On Thu, Oct 22, 2020 at 11:05:07PM +0100, Russell King - ARM Linux admin wrote: > > > @@ -1001,9 +995,12 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) > > > pcie->realio.name = "PCI I/O"; > > > > > > pci_add_resource(&bridge->windows, &pcie->realio); > > > + ret = devm_request_resource(dev, &iomem_resource, &pcie->realio); > > > > I think you're trying to claim this resource against the wrong parent. > > Fixing this to ioport_resource results in in working PCIe. Copy-n-paste... Thanks for testing. Rob
On 23/10/2020 02:51, Rob Herring wrote: > On Thu, Oct 22, 2020 at 5:09 PM Russell King - ARM Linux admin > <linux@armlinux.org.uk> wrote: >> On Thu, Oct 22, 2020 at 11:05:07PM +0100, Russell King - ARM Linux admin wrote: >>>> @@ -1001,9 +995,12 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) >>>> pcie->realio.name = "PCI I/O"; >>>> >>>> pci_add_resource(&bridge->windows, &pcie->realio); >>>> + ret = devm_request_resource(dev, &iomem_resource, &pcie->realio); >>> I think you're trying to claim this resource against the wrong parent. >> Fixing this to ioport_resource results in in working PCIe. > Copy-n-paste... Thanks for testing. > > Rob Run tested the patch with 5.9.1 and it seems fixing the issue, not sure about the meaning of "BAR 0: error updating": mvebu-pcie soc:pcie: host bridge /soc/pcie ranges: mvebu-pcie soc:pcie: Parsing ranges property... 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 mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe -> 0x0100000000 mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe -> 0x0100000000 mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe -> 0x0200000000 mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe -> 0x0200000000 mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe -> 0x0300000000 mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe -> 0x0300000000 mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe -> 0x0400000000 mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe -> 0x0400000000 mvebu-pcie soc:pcie: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [bus 00-ff] 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] pci_bus 0000:00: root bus resource [io 0x1000-0xeffff] pci_bus 0000:00: scanning bus pci 0000:00:01.0: [11ab:6820] type 01 class 0x060400 pci 0000:00:01.0: reg 0x38: [mem 0x00000000-0x000007ff pref] pci 0000:00:02.0: [11ab:6820] type 01 class 0x060400 pci 0000:00:02.0: reg 0x38: [mem 0x00000000-0x000007ff pref] pci 0000:00:03.0: [11ab:6820] type 01 class 0x060400 pci 0000:00:03.0: reg 0x38: [mem 0x00000000-0x000007ff pref] pci_bus 0000:00: fixups for bus pci 0000:00:01.0: scanning [bus 00-00] behind bridge, pass 0 pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci 0000:00:02.0: scanning [bus 00-00] behind bridge, pass 0 pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci 0000:00:03.0: scanning [bus 00-00] behind bridge, pass 0 pci 0000:00:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci 0000:00:01.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus 0000:01: scanning bus pci_bus 0000:01: fixups for bus pci_bus 0000:01: bus scan returning with max=01 pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 pci 0000:00:02.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus 0000:02: scanning bus pci 0000:02:00.0: [168c:003c] type 00 class 0x028000 pci 0000:02:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit] pci 0000:02:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref] pci 0000:02:00.0: supports D1 D2 pci 0000:00:02.0: ASPM: current common clock configuration is inconsistent, reconfiguring pci_bus 0000:02: fixups for bus pci_bus 0000:02: bus scan returning with max=02 pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02 pci 0000:00:03.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus 0000:03: scanning bus pci 0000:03:00.0: [168c:002e] type 00 class 0x028000 pci 0000:03:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit] pci 0000:03:00.0: supports D1 pci 0000:03:00.0: PME# supported from D0 D1 D3hot pci 0000:03:00.0: PME# disabled pci 0000:00:03.0: ASPM: current common clock configuration is inconsistent, reconfiguring pci_bus 0000:03: fixups for bus pci_bus 0000:03: bus scan returning with max=03 pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03 pci_bus 0000:00: bus scan returning with max=03 pci 0000:00:02.0: BAR 8: assigned [mem 0xe0000000-0xe02fffff] pci 0000:00:03.0: BAR 8: assigned [mem 0xe0300000-0xe03fffff] pci 0000:00:01.0: BAR 6: assigned [mem 0xe0400000-0xe04007ff pref] pci 0000:00:02.0: BAR 6: assigned [mem 0xe0500000-0xe05007ff pref] pci 0000:00:03.0: BAR 6: assigned [mem 0xe0600000-0xe06007ff pref] pci 0000:00:01.0: PCI bridge to [bus 01] pci 0000:02:00.0: BAR 0: assigned [mem 0xe0000000-0xe01fffff 64bit] pci 0000:02:00.0: BAR 0: error updating (0xe0000004 != 0xffffffff) pci 0000:02:00.0: BAR 0: error updating (high 0x000000 != 0xffffffff) pci 0000:02:00.0: BAR 6: assigned [mem 0xe0200000-0xe020ffff pref] pci 0000:00:02.0: PCI bridge to [bus 02] pci 0000:00:02.0: bridge window [mem 0xe0000000-0xe02fffff] pci 0000:03:00.0: BAR 0: assigned [mem 0xe0300000-0xe030ffff 64bit] pci 0000:03:00.0: BAR 0: error updating (0xe0300004 != 0xffffffff) pci 0000:03:00.0: BAR 0: error updating (high 0x000000 != 0xffffffff) pci 0000:00:03.0: PCI bridge to [bus 03] pci 0000:00:03.0: bridge window [mem 0xe0300000-0xe03fffff] pci 0000:00:03.0: enabling device (0140 -> 0142) pci 0000:00:03.0: enabling bus mastering pci 0000:00:02.0: enabling device (0140 -> 0142) pci 0000:00:02.0: enabling bus mastering ---- Pardon the ignorance, how the further workflow of the patch from patchwork, commit to next (5.10) branch and then backport to 5.9?
On Fri, Oct 23, 2020 at 4:19 AM ™֟☻̭҇ Ѽ ҉ ® <vtolkm@googlemail.com> wrote: > > On 23/10/2020 02:51, Rob Herring wrote: > > On Thu, Oct 22, 2020 at 5:09 PM Russell King - ARM Linux admin > > <linux@armlinux.org.uk> wrote: > >> On Thu, Oct 22, 2020 at 11:05:07PM +0100, Russell King - ARM Linux admin wrote: > >>>> @@ -1001,9 +995,12 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) > >>>> pcie->realio.name = "PCI I/O"; > >>>> > >>>> pci_add_resource(&bridge->windows, &pcie->realio); > >>>> + ret = devm_request_resource(dev, &iomem_resource, &pcie->realio); > >>> I think you're trying to claim this resource against the wrong parent. > >> Fixing this to ioport_resource results in in working PCIe. > > Copy-n-paste... Thanks for testing. > > > > Rob > > Run tested the patch with 5.9.1 and it seems fixing the issue, not sure > about the meaning of "BAR 0: error updating": > > > mvebu-pcie soc:pcie: host bridge /soc/pcie ranges: > mvebu-pcie soc:pcie: Parsing ranges property... > 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 > mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe -> 0x0100000000 > mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe -> 0x0100000000 > mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe -> 0x0200000000 > mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe -> 0x0200000000 > mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe -> 0x0300000000 > mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe -> 0x0300000000 > mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe -> 0x0400000000 > mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe -> 0x0400000000 > mvebu-pcie soc:pcie: PCI host bridge to bus 0000:00 > pci_bus 0000:00: root bus resource [bus 00-ff] > 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] > pci_bus 0000:00: root bus resource [io 0x1000-0xeffff] > pci_bus 0000:00: scanning bus > pci 0000:00:01.0: [11ab:6820] type 01 class 0x060400 > pci 0000:00:01.0: reg 0x38: [mem 0x00000000-0x000007ff pref] > pci 0000:00:02.0: [11ab:6820] type 01 class 0x060400 > pci 0000:00:02.0: reg 0x38: [mem 0x00000000-0x000007ff pref] > pci 0000:00:03.0: [11ab:6820] type 01 class 0x060400 > pci 0000:00:03.0: reg 0x38: [mem 0x00000000-0x000007ff pref] > pci_bus 0000:00: fixups for bus > pci 0000:00:01.0: scanning [bus 00-00] behind bridge, pass 0 > pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring > pci 0000:00:02.0: scanning [bus 00-00] behind bridge, pass 0 > pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring > pci 0000:00:03.0: scanning [bus 00-00] behind bridge, pass 0 > pci 0000:00:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring > pci 0000:00:01.0: scanning [bus 00-00] behind bridge, pass 1 > pci_bus 0000:01: scanning bus > pci_bus 0000:01: fixups for bus > pci_bus 0000:01: bus scan returning with max=01 > pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 > pci 0000:00:02.0: scanning [bus 00-00] behind bridge, pass 1 > pci_bus 0000:02: scanning bus > pci 0000:02:00.0: [168c:003c] type 00 class 0x028000 > pci 0000:02:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit] > pci 0000:02:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref] > pci 0000:02:00.0: supports D1 D2 > pci 0000:00:02.0: ASPM: current common clock configuration is > inconsistent, reconfiguring > pci_bus 0000:02: fixups for bus > pci_bus 0000:02: bus scan returning with max=02 > pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02 > pci 0000:00:03.0: scanning [bus 00-00] behind bridge, pass 1 > pci_bus 0000:03: scanning bus > pci 0000:03:00.0: [168c:002e] type 00 class 0x028000 > pci 0000:03:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit] > pci 0000:03:00.0: supports D1 > pci 0000:03:00.0: PME# supported from D0 D1 D3hot > pci 0000:03:00.0: PME# disabled > pci 0000:00:03.0: ASPM: current common clock configuration is > inconsistent, reconfiguring > pci_bus 0000:03: fixups for bus > pci_bus 0000:03: bus scan returning with max=03 > pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03 > pci_bus 0000:00: bus scan returning with max=03 > pci 0000:00:02.0: BAR 8: assigned [mem 0xe0000000-0xe02fffff] > pci 0000:00:03.0: BAR 8: assigned [mem 0xe0300000-0xe03fffff] > pci 0000:00:01.0: BAR 6: assigned [mem 0xe0400000-0xe04007ff pref] > pci 0000:00:02.0: BAR 6: assigned [mem 0xe0500000-0xe05007ff pref] > pci 0000:00:03.0: BAR 6: assigned [mem 0xe0600000-0xe06007ff pref] > pci 0000:00:01.0: PCI bridge to [bus 01] > pci 0000:02:00.0: BAR 0: assigned [mem 0xe0000000-0xe01fffff 64bit] > pci 0000:02:00.0: BAR 0: error updating (0xe0000004 != 0xffffffff) > pci 0000:02:00.0: BAR 0: error updating (high 0x000000 != 0xffffffff) Based on the logs in bugzilla, this was introduced between 5.4 and 5.8. > pci 0000:02:00.0: BAR 6: assigned [mem 0xe0200000-0xe020ffff pref] > pci 0000:00:02.0: PCI bridge to [bus 02] > pci 0000:00:02.0: bridge window [mem 0xe0000000-0xe02fffff] > pci 0000:03:00.0: BAR 0: assigned [mem 0xe0300000-0xe030ffff 64bit] > pci 0000:03:00.0: BAR 0: error updating (0xe0300004 != 0xffffffff) > pci 0000:03:00.0: BAR 0: error updating (high 0x000000 != 0xffffffff) > pci 0000:00:03.0: PCI bridge to [bus 03] > pci 0000:00:03.0: bridge window [mem 0xe0300000-0xe03fffff] > pci 0000:00:03.0: enabling device (0140 -> 0142) > pci 0000:00:03.0: enabling bus mastering > pci 0000:00:02.0: enabling device (0140 -> 0142) > pci 0000:00:02.0: enabling bus mastering > > ---- > > Pardon the ignorance, how the further workflow of the patch from > patchwork, commit to next (5.10) branch and then backport to 5.9? Once in 5.10-rc, it will be picked up by stable maintainers for all stable kernels. Rob
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c index c39978b750ec..c6fc8bd5e77f 100644 --- a/drivers/pci/controller/pci-mvebu.c +++ b/drivers/pci/controller/pci-mvebu.c @@ -960,25 +960,16 @@ static void mvebu_pcie_powerdown(struct mvebu_pcie_port *port) } /* - * We can't use devm_of_pci_get_host_bridge_resources() because we - * need to parse our special DT properties encoding the MEM and IO - * apertures. + * devm_of_pci_get_host_bridge_resources() only sets up translateable resources, + * so we need extra resource setup parsing our special DT properties encoding + * the MEM and IO apertures. */ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) { struct device *dev = &pcie->pdev->dev; - struct device_node *np = dev->of_node; struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie); int ret; - /* Get the bus range */ - ret = of_pci_parse_bus_range(np, &pcie->busn); - if (ret) { - dev_err(dev, "failed to parse bus-range property: %d\n", ret); - return ret; - } - pci_add_resource(&bridge->windows, &pcie->busn); - /* Get the PCIe memory aperture */ mvebu_mbus_get_pcie_mem_aperture(&pcie->mem); if (resource_size(&pcie->mem) == 0) { @@ -988,6 +979,9 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) pcie->mem.name = "PCI MEM"; pci_add_resource(&bridge->windows, &pcie->mem); + ret = devm_request_resource(dev, &iomem_resource, &pcie->mem); + if (ret) + return ret; /* Get the PCIe IO aperture */ mvebu_mbus_get_pcie_io_aperture(&pcie->io); @@ -1001,9 +995,12 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) pcie->realio.name = "PCI I/O"; pci_add_resource(&bridge->windows, &pcie->realio); + ret = devm_request_resource(dev, &iomem_resource, &pcie->realio); + if (ret) + return ret; } - return devm_request_pci_bus_resources(dev, &bridge->windows); + return 0; } /*
With commit 669cbc708122 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()"), the DT 'ranges' is parsed and populated into resources when the host bridge is allocated. The resources are requested as well, but that happens a 2nd time for the mvebu driver in mvebu_pcie_parse_request_resources(). We should only be requesting the additional resources added in mvebu_pcie_parse_request_resources(). These are not added by default because the use custom properties rather than standard DT address translation. Also, the bus ranges was also populated by default, so we can remove it from mvebu_pci_host_probe(). Fixes: 669cbc708122 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209729 Reported-by: vtolkm@googlemail.com Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Russell King <linux@armlinux.org.uk> Cc: linux-pci@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Rob Herring <robh@kernel.org> --- Untested, please test. drivers/pci/controller/pci-mvebu.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-)