From: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [[RFC PATCH v1] 1/1] PCI: Add pci=nobbn to ignore ACPI _BBN method to override host bridge bus window
Date: Fri, 17 Jan 2020 15:00:11 +0000 [thread overview]
Message-ID: <PSXP216MB043839BFAE70C02DB13DEA4A80310@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <87muandp8m.fsf@nanos.tec.linutronix.de>
On Thu, Jan 16, 2020 at 11:13:13PM +0100, Thomas Gleixner wrote:
> Nicholas,
>
> Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au> writes:
>
> > Add pci=nobbn kernel parameter.
> >
> > Override the host bridge bus resource to [bus 00-ff] when specified.
>
> Fine, but you completely fail to explain why this is useful and why
> someone would utilize this command line parameter.
There are motherboards with single PCIe root complex which give
significantly less than [bus 00-ff] via CRS. I own one with [bus 00-7f]
and have seen some with significantly less.
A user who wants to use more busses than the motherboard advertises will
want to use this kernel parameter, for instance if they have a lot of
PCIe switches or Thunderbolt 3 devices.
This is similar to how we have pci=nocrs to override motherboards with
issues. The bus resource is not overridden by pci=nocrs, even though it
will usually come from the same method. However, I believe it would be
unwise to change pci=nocrs to include bus resource, as detailed in my
original RFC.
>
> Thanks,
>
> tglx
Thanks,
Nicholas
next prev parent reply other threads:[~2020-01-17 15:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 21:30 [[RFC PATCH v1] 1/1] PCI: Add pci=nobbn to ignore ACPI _BBN method to override host bridge bus window Nicholas Johnson
2020-01-16 22:13 ` Thomas Gleixner
2020-01-17 15:00 ` Nicholas Johnson [this message]
2020-01-17 16:05 ` Bjorn Helgaas
2020-01-18 13:39 ` Nicholas Johnson
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=PSXP216MB043839BFAE70C02DB13DEA4A80310@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM \
--to=nicholas.johnson-opensource@outlook.com.au \
--cc=bhelgaas@google.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@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.