From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Sanath S <sanaths2@amd.com>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, mario.limonciello@amd.com,
Sanjay R Mehta <sanju.mehta@amd.com>
Subject: Re: [PATCH] PCI: Allocate maximum available buses to help extending the daisy chain
Date: Thu, 17 Aug 2023 13:24:30 +0300 [thread overview]
Message-ID: <20230817102430.GD3465@black.fi.intel.com> (raw)
In-Reply-To: <ffd5401b-400b-79e2-51f2-e6866251000f@amd.com>
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.
> > In case of a thunderbolt capable bridge, reconfigure the buses allocated
Thunderbolt
> > 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.
> > 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?
> > 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.
next prev parent reply other threads:[~2023-08-17 10:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-16 5:19 [PATCH] PCI: Allocate maximum available buses to help extending the daisy chain Sanath S
2023-08-16 13:18 ` Sanath S
2023-08-17 10:24 ` Mika Westerberg [this message]
2023-08-18 3:31 ` Sanath S
2023-08-18 4:56 ` Mika Westerberg
2023-08-22 14:36 ` Maciej W. Rozycki
2023-08-23 14:15 ` kernel test robot
2023-12-08 22:24 ` Bjorn Helgaas
2023-12-08 22:29 ` Mario Limonciello
2023-12-08 22:44 ` Bjorn Helgaas
2023-12-11 21:48 ` Mario Limonciello
2023-12-12 20:54 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230817102430.GD3465@black.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=sanaths2@amd.com \
--cc=sanju.mehta@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.