From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>,
Logan Gunthorpe <logang@deltatee.com>,
linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 2/2] PCI: Skip resource distribution when no hotplug bridges
Date: Tue, 25 Jun 2019 15:04:55 +0300 [thread overview]
Message-ID: <20190625120455.GF2640@lahna.fi.intel.com> (raw)
In-Reply-To: <c4daf43a302eeb1c507b9cf4a353200669e04ad8.camel@kernel.crashing.org>
On Tue, Jun 25, 2019 at 09:48:19PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2019-06-25 at 13:05 +0300, Mika Westerberg wrote:
> > > We only every distribute resources when using
> > > pci_assign_unassigned_bridge_resources which we only use some cases,
> > > and it's completely non obvious why we would use it there and not in
> > > other places.
> >
> > We added it only for native PCIe hotplug path with the assumption that
> > the boot firmware takes care of the initial resource allocation. I don't
> > see any particular reason why it could not be called for other paths as
> > well, though.
>
> Ok, we need to look into this for all the platforms who just reassign
> everything in Linux (ie, ignore whatever the boot firmware did, if it
> did anything).
>
> I feel like all these platforms today will have a hard time getting
> anything useful out of hotplug with our default "2M" add to the hotplug
> bridges :)
Yeah, at least if Thunderbolt is involved each "daisy-chained" device
adds a complete PCIe switch running out of resources rather quick.
> > > We also don't distribute during the initial root survey meaning afaik
> > > that we get toast for any hotplug bridge that has stuff already there
> > > at boot.
> >
> > The boot firmware obviously needs to follow the same logic. AFAICT
> > recent PCs and Macs using native PCIe hotplug handle it.
>
> What's your experience in that area ? How (well) do they handle it in
> the boot firmware ? at least on arm64, boot firmwares are rather
> catastrophic when it comes to PCI, and on other embedded devices they
> are basically non-existent.
Well my experience is quite limited to recent Macs and PCs which usually
handle the initial resource allocation just fine. In case of Thunderbolt
some "older" PCs handle everything in firmware, even the runtime
resource allocation via SMI handler accompanied with ACPI hotplug.
next prev parent reply other threads:[~2019-06-25 12:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-22 21:03 [PATCH 0/2] PCI: Simplify pci_bus_distribute_available_resources() Bjorn Helgaas
2019-06-22 21:03 ` [PATCH 1/2] " Bjorn Helgaas
2019-06-24 11:09 ` Mika Westerberg
2019-06-24 16:21 ` Logan Gunthorpe
2019-06-22 21:03 ` [PATCH 2/2] PCI: Skip resource distribution when no hotplug bridges Bjorn Helgaas
2019-06-24 11:24 ` Mika Westerberg
2019-06-24 23:45 ` Benjamin Herrenschmidt
2019-06-25 10:05 ` Mika Westerberg
2019-06-25 11:48 ` Benjamin Herrenschmidt
2019-06-25 12:04 ` Mika Westerberg [this message]
2019-06-25 12:23 ` Benjamin Herrenschmidt
2019-06-25 12:43 ` Mika Westerberg
2019-06-25 23:22 ` Benjamin Herrenschmidt
2019-06-26 17:35 ` Bjorn Helgaas
2019-06-26 22:35 ` Benjamin Herrenschmidt
2019-06-24 16:26 ` Logan Gunthorpe
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=20190625120455.GF2640@lahna.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=nicholas.johnson-opensource@outlook.com.au \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox