linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "mika.westerberg@linux.intel.com" <mika.westerberg@linux.intel.com>
Cc: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"corbet@lwn.net" <corbet@lwn.net>
Subject: Re: [PATCH v6 1/4] PCI: Consider alignment of hot-added bridges when distributing available resources
Date: Mon, 17 Jun 2019 13:22:13 -0500	[thread overview]
Message-ID: <20190617182213.GB13533@google.com> (raw)
In-Reply-To: <20190617093513.GN2640@lahna.fi.intel.com>

On Mon, Jun 17, 2019 at 12:35:13PM +0300, mika.westerberg@linux.intel.com wrote:
> On Wed, May 22, 2019 at 02:30:44PM +0000, Nicholas Johnson wrote:
> > Rewrite pci_bus_distribute_available_resources to better handle bridges
> > with different resource alignment requirements. Pass more details
> > arguments recursively to track the resource start and end addresses
> > relative to the initial hotplug bridge. This is especially useful for
> > Thunderbolt with native PCI enumeration, enabling external graphics
> > cards and other devices with bridge alignment higher than 0x100000
>  
> Instead of 0x100000 you could say 1MB here.

And of course, 1MB is the minimum bridge window alignment.  I *guess*
this is actually talking about endpoints with BARs larger than 1MB,
which have to be aligned on their size.  This doesn't actually impose
any requirement on the bridge window alignment, as long as the bridge
window contains the endpoint BARs.

> > bytes.

> >  	for_each_pci_bridge(dev, bus) {
> > -		const struct resource *res;
> > +		struct resource *res;
> > +		resource_size_t used_size;
> 
> Here order these in "reverse christmas tree" like:
> 
> 		resource_size_t used_size;
> 		struct resource *res;

I actually don't enforce "reverse christmas tree", and when I write
code, I order the declarations in order of their use in the code
below, as Nicholas has done.  But either way is fine.

Bjorn

  reply	other threads:[~2019-06-17 18:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190522222928.2964-1-nicholas.johnson-opensource@outlook.com.au>
2019-05-22 14:30 ` [PATCH v6 1/4] PCI: Consider alignment of hot-added bridges when distributing available resources Nicholas Johnson
2019-06-15 19:56   ` Bjorn Helgaas
2019-06-17  9:21     ` mika.westerberg
2019-06-19 13:40     ` Nicholas Johnson
2019-06-19 21:53       ` Bjorn Helgaas
2019-06-17  9:35   ` mika.westerberg
2019-06-17 18:22     ` Bjorn Helgaas [this message]
2019-06-19 13:47     ` Nicholas Johnson
2019-05-22 14:30 ` [PATCH v6 2/4] PCI: Modify extend_bridge_window() to set resource size directly Nicholas Johnson
2019-06-15 19:57   ` Bjorn Helgaas
2019-05-22 14:31 ` [PATCH v6 3/4] PCI: Fix bug resulting in double hpmemsize being assigned to MMIO window Nicholas Johnson
2019-05-22 14:31 ` [PATCH v6 4/4] PCI: Add pci=hpmemprefsize parameter to set MMIO_PREF size independently 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=20190617182213.GB13533@google.com \
    --to=helgaas@kernel.org \
    --cc=corbet@lwn.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=nicholas.johnson-opensource@outlook.com.au \
    /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).