All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Chiang <achiang@hp.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: jbarnes@virtuousgeek.org, lenb@kernel.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org
Subject: Re: [PATCH v2 2/2] PCI Hotplug: acpiphp: get pci_bus from acpi handle correctly
Date: Tue, 21 Jul 2009 14:19:35 -0600	[thread overview]
Message-ID: <20090721201935.GL32046@ldl.fc.hp.com> (raw)
In-Reply-To: <200907211415.47628.bjorn.helgaas@hp.com>

* Bjorn Helgaas <bjorn.helgaas@hp.com>:
> On Tuesday 21 July 2009 01:57:55 pm Alex Chiang wrote:
> > * Bjorn Helgaas <bjorn.helgaas@hp.com>:
> > > On Tuesday 14 July 2009 02:53:33 pm Alex Chiang wrote:
> > > > +static struct pci_bus *pci_bus_from_handle(acpi_handle handle)
> > > > +{
> > > > +	struct pci_bus *pbus;
> > > > +
> > > > +	if (acpi_is_root_bridge(handle)) {
> > > > +		struct acpi_pci_root *root = acpi_pci_find_root(handle);
> > > > +		pbus = root->bus;
> > > > +	} else {
> > > > +		struct pci_dev *pdev = acpi_get_pci_dev(handle);
> > > > +		pbus = pdev->subordinate;
> > > > +		pci_dev_put(pdev);
> > > > +	}
> > > > +	return pbus;
> > > 
> > > I worry that acpi_is_root_bridge() merely checks the device IDs of
> > > "handle", which isn't quite the same as checking whether the pci_root
> > > driver has claimed "handle".
> > 
> > Hm, I understand this concern in a theoretical sense, but could
> > you explain more of what you're thinking about, and give me a
> > concrete example of something that might go wrong here?
> 
> My concern is only theoretical -- I could imagine a PNP0A03 device
> in the namespace (so acpi_is_root_bridge() is true) that has not been
> claimed by the pci_root driver (so acpi_pci_find_root() returns NULL).
> 
> I don't think this will happen in practice because pci_root can't be
> a module, but it's easier to analyze with just one check, since you
> can learn everything you need from acpi_pci_find_root() without also
> depending on acpi_is_root_bridge().

Ah, that makes sense.

I can respin one more time using your suggestion (although I'll
probably keep it factored out into a separate function).

Thanks.

/ac


      reply	other threads:[~2009-07-21 20:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-14 20:53 [PATCH v2 0/2] ACPI/PCI: export acpi_pci_root to find pci_bus correctly Alex Chiang
2009-07-14 20:53 ` [PATCH v2 1/2] ACPI: export acpi_pci_root and friends Alex Chiang
2009-07-14 20:53 ` [PATCH v2 2/2] PCI Hotplug: acpiphp: get pci_bus from acpi handle correctly Alex Chiang
2009-07-20 20:55   ` Bjorn Helgaas
2009-07-21 19:57     ` Alex Chiang
2009-07-21 20:15       ` Bjorn Helgaas
2009-07-21 20:19         ` Alex Chiang [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=20090721201935.GL32046@ldl.fc.hp.com \
    --to=achiang@hp.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --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 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.