Messages in this thread | | | Date | Fri, 18 Aug 2023 09:01:50 +0530 | Subject | Re: [PATCH] PCI: Allocate maximum available buses to help extending the daisy chain | From | Sanath S <> |
| |
On 8/17/2023 3:54 PM, Mika Westerberg wrote: > On Wed, Aug 16, 2023 at 06:48:35PM +0530, Sanath S wrote: >> Adding Mika. > Thanks! > >> On 8/16/2023 10:49 AM, Sanath S wrote: >>> In the case of Thunderbolt, it contains a PCIe switch and one or >>> more hotplug-capable PCIe downstream ports where the daisy chain >>> can be extended. >>> >>> Currently when a Thunderbolt Dock is plugged in during S5/Reboot, >>> System BIOS allocates a very minimal number of buses for bridges and >>> hot-plug capable PCIe downstream ports to enumerate the dock during >>> boot. Because of this, we run out of bus space pretty quickly when >>> more PCIe devices are attached to hotplug downstream ports in order >>> to extend the chain. >>> >>> Before: >>> +-04.0 >>> +-04.1-[63-c1]----00.0-[64-69]--+-00.0-[65]-- >>> | +-01.0-[66]-- >>> | +-02.0-[67]-- >>> | +-03.0-[68]-- >>> | \-04.0-[69]-- >>> +-08.0 > This is something the BIOS should be doing but for some reason it is > not on that particular system. Yes, BIOS should be doing it. Idea here is if BIOS has not distributed it correctly, OS can reallocate and distribute it correctly. >>> In case of a thunderbolt capable bridge, reconfigure the buses allocated > Thunderbolt Will correct it. > >>> by BIOS to the maximum available buses. So that the hot-plug bridges gets >>> maximum buses and chain can be extended to accommodate more PCIe devices. >>> This fix is necessary for all the PCIe downstream ports where the daisy >>> chain can be extended. > This is necessary only when there is no proper BIOS allocation for the > resources. Yes, will send out a v2 with updated commit message. > >>> After: >>> +-04.0 >>> +-04.1-[63-c1]----00.0-[64-c1]--+-00.0-[65]-- >>> | +-01.0-[66-84]-- >>> | +-02.0-[85-a3]-- >>> | +-03.0-[a4-c0]-- >>> | \-04.0-[c1]-- >>> +-08.0 >>> >>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216000 > Did you get confirmation that this actually solves the issue? I've tested this on my setup, it is resolving the issue. > >>> Signed-off-by: Sanjay R Mehta <sanju.mehta@amd.com> >>> Signed-off-by: Sanath S <Sanath.S@amd.com> >>> --- >>> drivers/pci/probe.c | 9 +++++++++ >>> 1 file changed, 9 insertions(+) >>> >>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c >>> index 8bac3ce02609..ab7e90ef2382 100644 >>> --- a/drivers/pci/probe.c >>> +++ b/drivers/pci/probe.c >>> @@ -1263,6 +1263,8 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev, >>> bool fixed_buses; >>> u8 fixed_sec, fixed_sub; >>> int next_busnr; >>> + int start = bus->busn_res.start; >>> + int end = bus->busn_res.end; >>> /* >>> * Make sure the bridge is powered on to be able to access config >>> @@ -1292,6 +1294,13 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev, >>> broken = 1; >>> } >>> + /* Reconfigure, If maximum buses are not allocated */ >>> + if (!pass && start != 0 && end != 0xff && subordinate != end) { >>> + pci_info(dev, "Bridge has subordinate 0x%x but max busn 0x%x, reconfiguring\n", >>> + subordinate, end); >>> + broken = 1; >>> + } >>> + >>> /* >>> * Disable Master-Abort Mode during probing to avoid reporting of >>> * bus errors in some architectures.
| |