mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Len Brown <lenb@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org
Subject: Re: [PATCH 0/4] ACPI: kill acpi_pci_root_start
Date: Fri, 05 Oct 2012 00:36:52 +0200	[thread overview]
Message-ID: <1938257.EXdpWtCqiy@vostro.rjw.lan> (raw)
In-Reply-To: <CAE9FiQXDBaiwckKsUi4k34=O1GnkTOJf+mG33cKHDp8RGqrsnA@mail.gmail.com>

On Thursday 04 of October 2012 15:01:21 Yinghai Lu wrote:
> On Thu, Oct 4, 2012 at 2:53 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Thursday 04 of October 2012 14:31:46 Yinghai Lu wrote:
> >> On Thu, Oct 4, 2012 at 2:23 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> >>
> >> >> At last we could remove all acpi_bus_start workaround.
> >> >
> >> > Do I understand correctly that you just want to prevent acpi_pci_root_driver
> >> > from binding to the host bridge's struct acpi_device created while we're
> >> > walking the ACPI namespace?
> >>
> >> yes, during hot add path.
> >
> > Why exactly do you want to prevent that from happening?
> >
> 
> during adding pci root bus hotplug, Bjorn found some unsafe searching
> that caused by pci_bus_add_devices.

Do you have a link to a description of that problem?

> pci devices are created during pci scan root, but until very late
> acpi_pci_root_start call pci_bus_add_devices.

So you mean that pci_bus_add_devices() is called too late, right?

> To fill the gap, we need to move pci_bus_add_devices to acpi_pci_root_add
> at first.
> 
> but after we move that there, pci device will be added to device tree, and it
> will try to bind with acpi devices that should be under acpi pci root,
> but are not
> created yet. because device_add for acpi_device for acpi pci root is done yet.
> it still calling the .add in the acpi_driver aka acpi_pci_root_add.

Quite obviously, we haven't walked the ACPI namespace below the host bridge
object yet at that point.

> So I want to hold the driver attach for pci root acpi devices, and
> later attach it
> until pci devices created.
> 
> booting path, all acpi devices get created, and attach driver for them
> one by one.

I see.

Your patches seem to affect all devices in the ACPI namespace added after
boot, though, not only host bridges.

And the problem seems to be that the scanning of the ACPI namespace and
configuring the host bridge are kind of independent operations now.  What
we should do, actually, seems to be something like this:

(1) Configure the host bridge when discovered (i.e. do what the current
    acpi_pci_root_add() does.
(2) Parse the ACPI namespace under the host bridge (without binding ACPI
    drivers to the struct acpi_device objects created in the process,
    because they are known to correspond to PCI devices).
(3) Run pci_bus_add_devices() for the bridge.

in one routine.

What do you think?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

  reply	other threads:[~2012-10-04 22:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAE9FiQWgvVqnTTeYFvxf1GxLcEEeRyN-uSKPdg3o69oCpm43sQ@mail.gmail.com>
2012-10-03 23:00 ` Yinghai Lu
2012-10-03 23:00   ` [PATCH 1/4] ACPI: add drivers_autoprobe in struct acpi_device Yinghai Lu
2012-10-04 13:03     ` Konrad Rzeszutek Wilk
2012-10-04 15:15       ` Yinghai Lu
2012-10-09 16:38         ` Konrad Rzeszutek Wilk
2012-10-03 23:00   ` [PATCH 2/4] ACPI: use device drivers_autoprobe to delay loading acpi drivers Yinghai Lu
2012-10-03 23:00   ` [PATCH 3/4] PCI, ACPI: Remove not used acpi_pci_root_start() Yinghai Lu
2012-10-03 23:00   ` [PATCH 4/4] ACPI: remove acpi_op_start workaround Yinghai Lu
2012-10-04 12:57     ` Konrad Rzeszutek Wilk
2012-10-04 17:47   ` [PATCH 0/4] ACPI: kill acpi_pci_root_start Bjorn Helgaas
2012-10-04 18:36     ` Yinghai Lu
2012-10-04 19:44       ` Bjorn Helgaas
2012-10-04 19:54         ` Rafael J. Wysocki
2012-10-04 20:14         ` Yinghai Lu
2012-10-04 20:47           ` Bjorn Helgaas
2012-10-04 19:53     ` Rafael J. Wysocki
2012-10-04 21:23   ` Rafael J. Wysocki
2012-10-04 21:31     ` Yinghai Lu
2012-10-04 21:53       ` Rafael J. Wysocki
2012-10-04 22:01         ` Yinghai Lu
2012-10-04 22:36           ` Rafael J. Wysocki [this message]
2012-10-04 22:46             ` Yinghai Lu
2012-10-05 23:01               ` Rafael J. Wysocki
2012-10-05 23:10                 ` Yinghai Lu
2012-10-08 20:12                   ` Rafael J. Wysocki

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=1938257.EXdpWtCqiy@vostro.rjw.lan \
    --to=rjw@sisk.pl \
    --cc=akpm@linux-foundation.org \
    --cc=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=yinghai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®