All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Patterson <andrew.patterson@hp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-pci@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	jbarnes@virtuousgeek.org,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Subject: Re: [PATCH 0/1] Recurse when searching for empty slots in resources trees
Date: Tue, 16 Jun 2009 16:51:43 -0600	[thread overview]
Message-ID: <1245192703.8234.226.camel@bluto.andrew> (raw)
In-Reply-To: <alpine.LFD.2.01.0906161511390.16802@localhost.localdomain>

On Tue, 2009-06-16 at 15:19 -0700, Linus Torvalds wrote:
> 
> On Tue, 16 Jun 2009, Andrew Patterson wrote:
> >
> > I recently ran into a resource collision problem where PCI hot-plug
> > operations are failing for certain PCI topologies.  One case
> > illustrating the problem is using a QLogic PCIe HBA in a slot with a
> > PCIe root port as its parent bus.  Here is an abbreviated lspci output
> > for this topology:
> 
> I think the problem is real, but the fix is wrong.
> 
> > After boot, the resource tree looks like:
> > 
> > f0000000-fdffffff : PCI Bus 0000:c3
> >   f0000000-fdffffff : PCI Bus 0000:c2
> 
> So the problem is 9if I get this correctly) that c3 should be _inside_ c2. 

That is at least one problem. I initially tried reparenting this stuff.
That is what got backed out in
http://thread.gmane.org/gmane.linux.kernel/768526/

> No?
> 
> But you fix it by making find_resource always go as deep as it can (if I 
> read the code correctly).

Well, just deep enough.

>  Which is not necessarily always what we want 
> either - we've had this kind of confusion before, and the problem is that 
> different users of find_resource simply want different thing

find_resources is only called by allocate_resources, which in turn is
called in about 15 places. I think this change won't affect callers
other than pci_bus_alloc_resource as I am careful to maintain current
behavior as much as possible.

Is there a reason that find_resources should stop at the roots immediate
child/sibling.  It seems like a bug to me. Hence this patch.

> 
> The deeper problem (I think) is that the whole "find c3 resource" thing 
> should not have started from the root IN THE FIRST PLACE. I think it 
> should have started from its parent resources (and then, as a special 
> case, if the parent is transparent, look into the parent of the parent, 
> etc - in which case it can easily end up in the root in the end, but only 
> if it couldn't fit things in a parent window).
> 
> And I'm almost certain that I've seen that patch from Ivan at some point, 
> but it was after the merge window closed so it didn't get merged.
> 
> Ivan? Or anybody else who remembers the patch?
> 
> 		Linus
> 
-- 
Andrew Patterson
Hewlett-Packard


  reply	other threads:[~2009-06-16 22:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-16 22:04 [PATCH 0/1] Recurse when searching for empty slots in resources trees Andrew Patterson
2009-06-16 22:04 ` [PATCH] " Andrew Patterson
2009-06-16 22:19 ` [PATCH 0/1] " Linus Torvalds
2009-06-16 22:51   ` Andrew Patterson [this message]
2009-06-16 23:05     ` Linus Torvalds
2009-06-16 23:32       ` Linus Torvalds
2009-06-17 14:45         ` Ivan Kokshaysky
2009-06-17 16:28           ` Linus Torvalds
2009-06-16 23:38       ` Andrew Patterson
2009-06-16 23:56         ` Linus Torvalds
2009-06-17  0:19           ` Linus Torvalds
2009-06-17  1:04             ` Linus Torvalds
2009-06-17  3:19               ` Andrew Patterson
2009-06-17  4:19                 ` Linus Torvalds
2009-06-17  0:28           ` Jesse Barnes
2009-06-17 16:03             ` Alex Chiang
2009-06-17  9:13 ` Kenji Kaneshige
2009-06-17 13:43   ` Matthew Wilcox
2009-06-17 16:23     ` Linus Torvalds
2009-06-17 17:42       ` Andrew Patterson
2009-06-17 18:12         ` Linus Torvalds
2009-06-17 20:08           ` Andrew Patterson
2009-06-17 20:12             ` Linus Torvalds
2009-06-17 20:17               ` Matthew Wilcox

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=1245192703.8234.226.camel@bluto.andrew \
    --to=andrew.patterson@hp.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.