linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: linux-arch@vger.kernel.org, Chris Zankel <chris@zankel.net>,
	Grant Grundler <grundler@parisc-linux.org>,
	linux-parisc@vger.kernel.org, Matthew Wilcox <matthew@wil.cx>,
	Kyle McMartin <kyle@parisc-linux.org>,
	linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
	linux-pci@atrey.karlin.mff.cuni.cz,
	linux-arm-kernel@lists.arm.linux.org.uk,
	Russell King <rmk@arm.linux.org.uk>
Subject: Re: [patch 4/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations
Date: Tue, 19 Feb 2008 17:31:07 +1100	[thread overview]
Message-ID: <1203402667.6740.94.camel@pasglop> (raw)
In-Reply-To: <20080219044307.878416912@ldl.fc.hp.com>


On Mon, 2008-02-18 at 21:39 -0700, Bjorn Helgaas wrote:
>     powerpc: has a different collision check at (5)

I've always found the collision check dodgy. I tend to want to keep
the way powerpc does it here.

pci_enable_device() should only enable resources that have successfully
been added to the resource tree (that have passed all the collision
check etc...). There is a simple & clear indication of that: res->parent
is non-NULL. I think that is a better check than the test x86 does on
start and end.

That is, whatever the arch code decides to use to decide whether
resources are assigned by firmware or by the first pass assignment code
or not and collide or not, once that phase is finished (which is the
case when calling pcibios_enable_device(), having the resource in the
resource-tree or not is, I believe, the proper way to test whether it's
a useable resource.

Ben.

  reply	other threads:[~2008-02-19  6:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-19  4:39 [patch 0/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations Bjorn Helgaas
2008-02-19  4:39 ` [patch 1/4] PCI: split pcibios_enable_resources() out of pcibios_enable_device() Bjorn Helgaas
2008-02-19  6:27   ` Benjamin Herrenschmidt
2008-02-19  4:39 ` [patch 2/4] ppc: make pcibios_enable_device() use pcibios_enable_resources() Bjorn Helgaas
2008-02-19  6:26   ` Benjamin Herrenschmidt
2008-02-19  4:39 ` [patch 3/4] xtensa: " Bjorn Helgaas
2008-02-19  4:39 ` [patch 4/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations Bjorn Helgaas
2008-02-19  6:31   ` Benjamin Herrenschmidt [this message]
2008-02-19 16:11     ` Bjorn Helgaas
2008-02-19 17:08       ` Ivan Kokshaysky
2008-02-19 20:21       ` Benjamin Herrenschmidt
2008-02-19  6:33   ` Benjamin Herrenschmidt
2008-02-19  7:03   ` Kyle McMartin
2008-02-19  6:11 ` [patch 0/4] " Kyle McMartin
2008-02-19  8:09 ` Russell King
2008-02-19 10:08   ` Benjamin Herrenschmidt
2008-02-19 18:02     ` Bjorn Helgaas
2008-02-20  6:24 ` Grant Grundler

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=1203402667.6740.94.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=chris@zankel.net \
    --cc=grundler@parisc-linux.org \
    --cc=kyle@parisc-linux.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=matthew@wil.cx \
    --cc=paulus@samba.org \
    --cc=rmk@arm.linux.org.uk \
    /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).