From: Bjorn Helgaas <helgaas@kernel.org>
To: Jim Quinlan <james.quinlan@broadcom.com>
Cc: "open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS"
<linux-pci@vger.kernel.org>,
"maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE"
<bcm-kernel-feedback-list@broadcom.com>,
Bjorn Helgaas <bhelgaas@google.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH v1] PCI: pcie_bus_config can be set at build time
Date: Thu, 10 Sep 2020 08:31:55 -0500 [thread overview]
Message-ID: <20200910133155.GA782074@bjorn-Precision-5520> (raw)
In-Reply-To: <CA+-6iNzyuVm4gw2socQuQtdrXWCam3GfQj61jYJEUa75fnbvtQ@mail.gmail.com>
On Thu, Sep 10, 2020 at 08:57:10AM -0400, Jim Quinlan wrote:
> Hi Bjorn,
>
> On Wed, Sep 9, 2020 at 10:25 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> >
> > On Tue, Sep 08, 2020 at 12:32:48PM -0400, Jim Quinlan wrote:
> > > The Kconfig is modified so that the pcie_bus_config setting can be done at
> > > build time in the same manner as the CONFIG_PCIEASPM_XXXX choice. The
> > > pci_bus_config setting may still be overridden by the bootline param.
> >
> > I guess... I really hate these build-time config settings for both
> > ASPM and MPS/MRRS. But Linux just isn't smart or flexible enough to
> > do the right thing at run-time, so I guess we're kind of stuck.
> >
> > I guess you have systems where you need a different default?
>
> Yes, we've been shipping our kernel with the DEFAULT and since we do
> not have FW it is not configured optimally. Some customers have
> noticed and I tell them to put 'pci=pcie_bus_safe' on their bootline
> but I'd rather have this setting work for all customers as it yields
> the option we want.
I'm guessing you probably don't have any hotplug slots. Seems like we
ought to be able to recognize that and pick pcie_bus_safe
automatically. Someday.
Maybe that's part of the description: if you have a closed system with
no possibility of adding new devices, we can use the largest MPS
that's supported by all devices, i.e., pcie_bus_safe.
> > It'd be nice if we could put a little more detail in the Kconfig to
> > help users choose the correct one. "Ensure MPS matches upstream
> > bridge" is *accurate*, but it doesn't really tell me why I would
> > choose this rather than a different one.
>
> IIRC I just copied the comments that were in the bootline settings.
> I'm concerned about there being the same comment in two places; sooner
> or later someone will update one place and not the other.
True. It'd be nice if we at least had *one* place with a useful
description. I don't think we have any today.
Bjorn
prev parent reply other threads:[~2020-09-10 21:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-08 16:32 [RESEND PATCH v1] PCI: pcie_bus_config can be set at build time Jim Quinlan
2020-09-10 2:25 ` Bjorn Helgaas
2020-09-10 12:57 ` Jim Quinlan
2020-09-10 13:31 ` Bjorn Helgaas [this message]
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=20200910133155.GA782074@bjorn-Precision-5520 \
--to=helgaas@kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bhelgaas@google.com \
--cc=james.quinlan@broadcom.com \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox