All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: "Tang, Jason (ES)" <Jason.Tang2@ngc.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v0 00/13] PCI: Static Enumeration
Date: Wed, 27 May 2015 17:51:16 -0500	[thread overview]
Message-ID: <20150527214725.GE10210@google.com> (raw)
In-Reply-To: <f10f623e0316433abe30420d68f73e33@XCGVAG27.northgrum.com>

On Wed, May 27, 2015 at 08:58:38PM +0000, Tang, Jason (ES) wrote:
> ...
> Q1: Doesn't PCI Hotplug already solve this problem?
> A1: From what I can tell, the existing PCI Hotplug infrastructure only
>     works with PCI endpoints; it has no way to handle hot adding a
>     bridge, and then later on hot adding an endpoint.

__pci_bus_size_bridges() uses pci_hotplug_mem_size (default 2MB,
overridable with "pci=hpmemsize=") to reserve space for things that may be
hot-added below a bridge that supports hotplug.  The thing that's added may
be a bridge, and that bridge might support hotplug, and it should work at
hot-add a device below that bridge.

So in principle, this should work, but there might be something broken.

If you conclude it "has no way to handle hot adding a bridge," there must
be something seriously broken, and I'd like to fix that, even if it's not
sufficient to deal with your whole situation.

Can you post a complete dmesg log showing the two hot-adds and the failure?

>     Static enumeration can also be used in cases where the memory
>     behind a bridge needs to be changed due to faulty hardware.

Can you elaborate on this a bit?  Are you saying you have a piece of
defective hardware, and you can avoid the defect by assigning different
addresses to it?

> Q2: Why do bus numbers need to be reenumerated?
> A2: Consider a bus "A", with secondary bus number 1), has two child
>     buses, "B" and "C". Suppose that "B" has no grandchild buses, so
>     let its bus range is [2-2]. Likewise, "C" also has no grandchild
>     buses, so its bus range is [3-3]. Therefore, "A"'s bus range is
>     [1-3]. Let a new bridge "D" be hot added under "B". This bridge's
>     bus needs to be within its parent's bus range, but "B" has no
>     space for it. If "B" were to be dynamically resized to [2-3], then
>     "C"'s bus number would now be invalid.

I would expect to see a dev->is_hotplug_bridge test in the bridge
enumeration path (maybe somewhere in pci_scan_bridge()) so we could
reserve some bus numbers for future hot adds.  But I don't, so maybe
this is just a bug.

There's a lot of this stuff that works fairly well as long as the BIOS has
preconfigured things.  If your BIOS doesn't do that, I could certainly
believe it wouldn't work as well.  I would prefer to make Linux work better
and depend less on BIOS if we can.

Bjorn

  reply	other threads:[~2015-05-27 22:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-27 20:58 [PATCH v0 00/13] PCI: Static Enumeration Tang, Jason (ES)
2015-05-27 22:51 ` Bjorn Helgaas [this message]
2016-01-19 18:30 ` Bruno Santos
2015-05-28 23:24 Tang, Jason (ES)
2015-05-29 16:54 ` Bjorn Helgaas
2015-05-29 21:14 Tang, Jason (ES)
2015-05-29 21:49 ` Bjorn Helgaas
2015-06-01 21:46 Tang, Jason (ES)
2016-01-19 19:23 Tang, Jason (ES)
2016-01-21 18:25 Tang, Jason (ES)

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=20150527214725.GE10210@google.com \
    --to=bhelgaas@google.com \
    --cc=Jason.Tang2@ngc.com \
    --cc=linux-pci@vger.kernel.org \
    /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.