From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Lukas Wunner <lukas@wunner.de>,
"Chris Chiu" <chris.chiu@canonical.com>,
<linux-pci@vger.kernel.org>
Subject: Re: [PATCH v3 0/2] PCI: Distribute resources for root buses
Date: Fri, 2 Dec 2022 17:07:38 +0000 [thread overview]
Message-ID: <20221202170738.000053d8@Huawei.com> (raw)
In-Reply-To: <20221130112221.66612-1-mika.westerberg@linux.intel.com>
On Wed, 30 Nov 2022 13:22:19 +0200
Mika Westerberg <mika.westerberg@linux.intel.com> wrote:
> Hi all,
>
> This is third iteration of the patch series trying to solve the problem
> reported by Chris Chiu [1]. In summary the current resource
> distribution code does not cover the initial device enumeration so if we
> find unconfigured bridges they get the bare minimum.
>
> This one tries to be slightly more generic and deal with PCI devices in
> addition to PCIe. I've tried this on a system with Maple Ridge
> Thunderbolt controller (the same as in the orignal bug report), on QEMU
> with similar PCI topology using following parameters:
>
> -device pcie-pci-bridge,id=br1 \
> -device e1000,bus=br1,addr=2 \
> -device pci-bridge,chassis_nr=1,bus=br1,shpc=off,id=br2,addr=3 \
> -device e1000,bus=br1,addr=4 \
> -device e1000,bus=br2
>
> Then on a QEMU similar to what Jonathan used when he found out the
> regression with multifunction devices:
>
> -device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
> -device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
> -device e1000,bus=root_port13,addr=0.1 \
> -device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
> -device e1000,bus=fun1
>
> The previous versions of the series can be found:
>
> v2: https://lore.kernel.org/linux-pci/20221114115953.40236-1-mika.westerberg@linux.intel.com/
> v1: https://lore.kernel.org/linux-pci/20221103103254.30497-1-mika.westerberg@linux.intel.com/
>
> Changes from v2:
> * Make both patches to work with PCI devices too (do not expect that
> the bridge is always first device on the bus).
> * Allow distribution with bridges that do not have all resource
> windows programmed (thereofore the pathch 2/2 is not revert anymore)
patch
> * I did not add the tags from Rafael and Jonathan because the code is
> not exactly the same anymore so was not sure if they still apply.
Fair enough - guess it's time for another look.
>
> Changes from v1:
> * Re-worded the commit message to hopefully explain the problem better
> * Added Link: to the bug report
> * Update the comment according to Bjorn's suggestion
> * Dropped the ->multifunction check
> * Use %#llx in log format.
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=216000
>
> Mika Westerberg (2):
> PCI: Take other bus devices into account when distributing resources
> PCI: Distribute available resources for root buses too
>
> drivers/pci/setup-bus.c | 122 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 117 insertions(+), 5 deletions(-)
>
prev parent reply other threads:[~2022-12-02 17:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-30 11:22 [PATCH v3 0/2] PCI: Distribute resources for root buses Mika Westerberg
2022-11-30 11:22 ` [PATCH v3 1/2] PCI: Take other bus devices into account when distributing resources Mika Westerberg
2022-12-02 17:45 ` Jonathan Cameron
2022-12-02 23:35 ` Bjorn Helgaas
2022-12-02 23:34 ` Bjorn Helgaas
2022-12-05 7:28 ` Mika Westerberg
2022-12-05 22:46 ` Bjorn Helgaas
2022-11-30 11:22 ` [PATCH v3 2/2] PCI: Distribute available resources for root buses too Mika Westerberg
2022-12-02 18:01 ` Jonathan Cameron
2022-12-02 17:07 ` Jonathan Cameron [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=20221202170738.000053d8@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=chris.chiu@canonical.com \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael.j.wysocki@intel.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 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.