From: Yinghai Lu <yinghai@kernel.org>
To: Ruud <netwerkforens@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: PCIe bus (re-)numbering
Date: Sat, 19 Sep 2015 14:35:55 -0700 [thread overview]
Message-ID: <CAE9FiQXaOkMKk2PddYOXApK9tKLkgusH18sYgvLHA04BRdXR-g@mail.gmail.com> (raw)
In-Reply-To: <CAKsTQnn-+13Q=+hM581p=dvWnZXtnG6W-t5K4-ioNUTkEmyLMg@mail.gmail.com>
On Sat, Sep 19, 2015 at 1:20 AM, Ruud <netwerkforens@gmail.com> wrote:
> Hello all,
>
> Not a patch, not a complaint: a start of a discussion on PCIe bus
> renumbering and bus numbering in general..
>
>
> The current algorithm seems to allocate 8 extra busnumbers at the
> hotplug switch, but clearly 8 is not sufficient for the whole tree
> when it is discovered after initial numbering has been assigned. As
> the PCIe routing requires the bus numbers to be consecutive as it
> describes ranges there are not that many allocation strategies for bus
> numbers. It is impossible to predict at boot-time which switch will
> require lots of busses and which do not.
Well, if you need more than 8 bus number then practical way is
booting with pcie switch and late only hot-remove and host-add
instead of code hot-add.
>
> A solution is static assignment (e.g. as described by
> http://article.gmane.org/gmane.linux.kernel.pci/45212), but it seems
> not convenient to me.
Interesting, one patch in that thread looks like try to use bus range blindly.
so it is no go.
>
> I got the impression the most elegant way is to renumber, but at the
> same time I doubt. Would the BIOS become confused? Currently the
> kernel becomes confused as it renumbers the ethernet interfaces when
> the bus-numbers change. Several drivers seem to be locked to the
> device by its geographical routing (aka bus << 16 | device << 11 |
> function << 8 ). I got the impression that this is the root of the
> evil as the bus need not be as constant as expected.
Do you mean changing bus number without unloading driver ?
No, you can not do that.
some device firmware like lsi cards, if you change it's primary bus number,
the device will stop working, but that is another problem.
For cold hot add several pcie switches, right way would be have a script:
1. remove related children devices.
2. use setpci to clear bus number register
3. remove bridge devices
4. do pci rescan.
Yinghai
next prev parent reply other threads:[~2015-09-19 21:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-19 8:20 PCIe bus (re-)numbering Ruud
2015-09-19 21:35 ` Yinghai Lu [this message]
2015-09-20 9:17 ` Ruud
2015-09-20 17:03 ` Yinghai Lu
2015-09-21 7:49 ` Ruud
2015-09-21 14:06 ` Ruud
2015-09-21 21:22 ` Yinghai Lu
2015-09-29 14:04 ` Ruud
2015-09-29 15:36 ` Yinghai Lu
2015-09-21 21:22 ` Yinghai Lu
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=CAE9FiQXaOkMKk2PddYOXApK9tKLkgusH18sYgvLHA04BRdXR-g@mail.gmail.com \
--to=yinghai@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=netwerkforens@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).